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Preface 


The VMS Local Area VAXcluster Manual is a conceptual and tutorial guide 
that provides the cluster manager with information needed to 

• Understand the Local Area VAXcluster environment. 

• Perform installation, security, and network tailoring operations. 

• Perform various satellite configuration functions using the command 
procedure SATELLITE_CONFIG.COM. 


Intended Audience 

This document is intended primarily for users who are responsible for 
setting up a Local Area VAXcluster configuration and who have VMS system 
management experience. The document also presents guidelines to help 
users of satellite nodes function effectively in the cluster environment. 


Document Structure 

The VMS Local Area VAXcluster Manual contains four chapters and three 
appendixes. 

Chapter 1, Introduction to the Local Area VAXcluster Environment, presents 
an overview of the cluster environment and discusses basic setup issues. 

Chapter 2, Installation, Security, and Network Tailoring, explains how to 
perform these operations. 

Chapter 3, Configuring Satellite Nodes in the Cluster, explains how to 
add and remove satellite nodes, and how to modify the Ethernet hardware 
address for Micro VAX II and VAXstation II satellites, using the SATELLITE- 
CONFIG.COM command procedure. 

Chapter 4, Guidelines for Satellite Node Users, provides suggestions for users 
working in the Local Area VAXcluster environment. 

Appendix A, Installing the Operating System on MicroVAX II or VAXstation 
II Boot Nodes, explains procedures for installing the operating system on 
these nodes. 

Appendix B, Upgrading the Operating System on MicroVAX II or VAXstation 
II Boot Nodes, explains procedures for upgrading the operating system on 
these nodes. 


IX 
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Appendix C, Release Notes, contains information of interest to cluster 
managers. 


Associated Documents 

This manual does not describe day-to-day system management operations, 
such as establishing user accounts, setting up queues, monitoring 
performance, and so forth. Nor does it discuss routine network management 
issues. For information on those topics, refer instead to the following 
documents: 

• VAX/VMS System Manager's Reference Manual 

• Guide to VAXclusters 

• Guide to VAX/VMS Performance Management 

• VAX/VMS Networking Manual 

• VAX/VMS Utility Reference Manuals 


Conventions 


Convention Meaning 

|ret 1 A symbol with a one- to three-character 

abbreviation indicates that you press a key on 
the terminal, for example, [ret]. 

|ctrl/x 1 The phrase CTRL/x indicates that you must press 

the key labeled CTRL while you simultaneously 
press another key, for example, CTRL/C, CTRL/Y, 
CTRL/O. In examples, this control key sequence is 
shown as A x, for example, A C, A Y, A 0, because that 
is how the system echoes control key sequences. 

$ SHOW TIME Command examples show in black letters all 

15-JUN-1987 11:55:22 output lines or prompting characters that the 

system prints or displays. All user-entered 
commands are shown in red letters. 


x 
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Convention 

Meaning 

$ TYPE MYFILE.DAT 

Vertical series of periods, or ellipsis, means either 
that not all the data that the system would display 
in response to the particular command is shown 
or that not all the data a user would enter is 
shown. 

file-spec, . . . 

Horizontal ellipsis indicates that additional 
parameters, values, or information can be entered. 

[logical-name] 

Square brackets indicate that the enclosed item 
is optional. (Square brackets are not, however, 
optional in the syntax of a directory name in a 
file specification or in the syntax of a substring 
specification in an assignment statement.) 

quotation marks 
apostrophes 

The term quotation marks is used to refer to 
double quotation marks ("). The term apostrophe 
(') is used to refer to a single quotation mark. 
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Introduction to the Local Area VAXcluster 
Environment 


Using Ethernet as the common interconnect. Local Area VAXcluster Software 
extends many benefits of the VAXcluster architecture to Micro VAX II, 

Micro VAX 2000, VAXstation II, and VAXstation 2000 systems. 

A single Ethernet may support multiple Local Area VAXcluster 
configurations, 1 each identified and secured by a unique group number 
and a cluster password. (For information on cluster security, see Section 2.3.) 

This chapter presents an overview of the Local Area VAXcluster environment. 
Chapters 2 and 3 explain software installation and cluster configuration 
procedures. Chapter 4 provides guidelines for users of cluster resources. 
Cluster managers may want to modify or supplement these guidelines to suit 
local conditions. 


1.1 Boot and Satellite Node Functions 

A Local Area VAXcluster configuration consists of one or two boot nodes and 
up to 26 satellite nodes. 

• A boot node is both a management center for the cluster and a major 
resource provider. Its system disk contains the cluster common files for 
startup, authorization, and queue setup, as well as the directory roots 
from which the satellite nodes are booted. (The cluster manager creates 
these directory roots—one for each satellite—using the SATELLITE _ 
CONFIG.COM command procedure, described in Chapter 3.) 

A boot node makes available to the cluster such resources as user and 
application data disks, printers, and distributed batch processing facilities. 

In a Local Area VAXcluster configuration, a boot node may be any VAX 
system except VAX-11/725 or VAX-11/730, or it may be one of the 
following Micro VAX II or VAXstation II systems: 

— Micro VAX II with an RA series system disk. 

— Micro VAX II with an RD54 system disk, or VAXstation II with an 
RD54 or any larger system disk. Note that these boot nodes support 
a maximum of three satellites. In addition, it is recommended that 
the satellites use local RD series disks for paging and swapping. 


1 Subject to restrictions listed in Section C.3. 
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• The satellite nodes are booted remotely from a boot node's system disk. 
Generally, these nodes are consumers of cluster resources, though they 
may also sometimes provide disk serving and batch processing resources 
If satellite nodes are equipped with RD series disks, they may, for 
enhanced performance, use such local disks for paging and swapping. 

Satellite nodes may be any of the following: 

- Micro VAX II 

- Micro VAX 2000 
— VAXstation II 

— VAXstation 2000 

- VAXstation II/GPX 

- VAXstation II/RC 

Caution 

All MicroVAX II and VAXstation II machines in a Local Area 
VAXcluster configuration must use Revision E (or later) QBUS 
Network Adapter (DEQNA) devices and must have at least 3MB 
memory. Diskless machines require at least 4MB memory. 


1.2 Typical Configurations 

Figures 1-1, 1-2, and 1-3 illustrate typical Local Area VAXcluster 
configurations. Note that the setup procedures described in Sections 2.1 
through 2.4 and in Chapter 3 are required for all configurations. Section 2.5 
describes procedures for setting up configurations like those shown in 
Figures 1-2 and 1-3. 
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Figure 1-1 Local Area VAXcluster Configuration with One Boot Node and One 
System Disk 
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Figure 1-2 Local Area VAXcluster Configuration with One Boot Node and Two 
System Disks 
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Figure 1-3 Local Area VAXcluster Configuration with Two Boot Nodes and Two 
System Disks 
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1.3 Planning Cluster Setup Operations 

The normal sequence of cluster setup operations is as follows. With a single 
exception (booting a newly added satellite node at its console terminal), you 
can execute these operations entirely on the boot node. 

1 Install the VMS operating system or upgrade kit. 

2 Install the Local Area VAXcluster Software key and configure the boot 
node for cluster operation. 

3 Install the DECnet-VAX key. 

4 Tailor the DECnet-VAX network for the cluster and start the network. 

5 Install optional software products. 

6 Add satellite nodes. 

Note that you can install optional (layered) software products at any time, 
following instructions in the appropriate installation documents. If possible, 
however, you should plan to install on a boot node any such products that 
you want to make available clusterwide before you add satellites , because 
the satellites will then have access to the software as soon as they join the 
cluster. 

In the case of MicroVMS Workstation Software, this strategy is particularly 
effective for the following reasons: 

• When you add workstation satellites, AUTOGEN will configure them for 
optimal operation. 

• Workstation software will be started automatically when the workstation 
satellites become active in the cluster. 

Chapters 2 and 3 discuss installation and management procedures that apply 
specifically to the Local Area VAXcluster environment. To perform routine 
system and network management tasks, you can, for the most part, follow 
procedures described in the VAX/VMS System Manager's Reference Manual, 
the VMS Local Area VAXcluster Manual, and the VAX/VMS Networking 
Manual. Note, however, that references in those documents to the Computer 
Interconnect (Cl) and Hierarchical Storage Controller (HSC) devices do not 
apply for Local Area VAXcluster configurations. 
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This chapter discusses the operations required to set up a Local Area 
VAXcluster configuration: 

• Installing and upgrading the operating system 

• Installing the Local Area VAXcluster Software key 

• Configuring a boot node for cluster operation and securing the cluster 

• Installing the DECnet-VAX key, tailoring the network for the cluster, and 
starting the network 

When you have completed these operations, you can add satellite nodes 
using the SATELLITE_CONFIG.COM command procedure described in 
Chapter 3. 

This chapter also provides instructions for configuring an extended cluster, 
using the following methods: 

• Adding another system disk to an existing boot node 

• Adding another boot node to an existing cluster 

• Setting up a new cluster with two boot nodes 

For information on these operations, refer to Section 2.5. Note that the setup 
operations described in Sections 2.1 through 2.4 are required for all Local 
Area VAXcluster configurations. 


2.1 Installing and Upgrading the Operating System 

To perform a new installation on VAX boot nodes, follow instructions in the 
installation booklets for your processor. To perform a new installation on 
Micro VAX II or VAXstation II boot nodes, refer to Appendix A. 

To upgrade the VMS operating system on VAX boot nodes, follow 
instructions in the VMS Version 4.6 Release Notes. To upgrade the VMS 
or Micro VMS operating system on Micro VAX II or VAXstation II boot nodes, 
refer to Appendix B. 
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Caution 

You must answer Y (or YES) when the installation or upgrade 
procedure asks if you want to generate a cluster common system 
disk. 

If you are upgrading an existing Version 4.5A or 4.5C Local Area 
VAXcluster configuration to Version 4.6, refer to Sections C.l 
and C.10.1 before starting the upgrade. 

Note that references in the installation and upgrade procedures to the 
Computer Interconnect (Cl) and to HSC-based system disks do not apply for 
Local Area VAXcluster configurations. 


2.2 Installing the Local Area VAXcluster Software Key and Configuring the 
Boot Node for Cluster Operation 

To install the Local Area VAXcluster Software key and configure the boot 
node for cluster operation, follow these steps: 

1 Locate the Local Area VAXcluster Software medium. 

2 Log in as system manager on the cluster boot node. 

3 Mount the medium in an appropriate drive and put it on line. 

4 Invoke the command procedure SYS$UPDATE:VMSINSTAL.COM to 
install the key, specifying as parameters LAV010 and the name of the 
device holding the medium. (To determine the appropriate device name, 
see the third column in Table A-2.) For example: 

$ ®SYS$UPDATE:VMSINSTAL LAV010 ddcu: 

When the installation is finished, VMSINSTAL displays a completion 
message and returns control to DCL command level. 

5 Execute the command procedure SYS$MANAGER:BOOT_ 
CONFIG.COM. When the procedure asks whether you want to configure 
a boot node or add another system disk, select the CONFIGURE 
function. (For information on adding another system disk, see 
Section 2.5.) 

The procedure then asks you to enter the following information: 

• The cluster group number. The group number uniquely identifies 
each Local Area VAXcluster configuration on a single Ethernet. This 
number must be in the range from 1 to 4095 or 61440 to 65535. 1 
Thus, if you plan to have more than one such cluster on a common 


1 If, during a previous Local Area VAXcluster installation, you have specified a group number outside the legal 
range, you must run the Cluster_Authorize Utility to specify a new group number and then reboot the entire 
cluster. (See Section 2.3.1.) 
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Ethernet at your site, be sure to specify a different group number for 
each. 

• The cluster password. The password controls access to the cluster. 

It must be from 1 to 31 alphanumeric characters in length and may 
include dollar signs and underscores. 

• The node's SCSSYSTEMID value. If you have performed a new 
installation of the VMS operating system, enter the value that you 
specified during that installation. 

• The node's DECnet node name. If you have performed a new 
installation of the VMS operating system, enter the name that 
you specified during that installation. 

• The number of boot nodes there will be in the cluster. If you plan to 
have only one boot node, enter 1. (For information on configuring 
another boot node, see Section 2.5.) 

Note that both group number and password are requirements of the 

security functions discussed in Section 2.3. 

When you have entered the information for which BOOT_ 

CONFIG.COM prompts, the procedure will run AUTOGEN to reboot the 

system with cluster software running. 

Example 2-1 shows a typical interactive BOOT_CONFIG.COM session for 
boot node JOHNY. 
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Example 2—1 Sample Interactive BOOT_CONFIG.COM CONFIGURE Session 


$ 0BOOT_CONFIG.COM 

Boot Node Configuration Procedure 

This procedure can CONFIGURE a Local Area VAXcluster boot node 
or ADD another system disk. 

CONFIGURE a boot node or ADD another system disk [CONFIGURE]? [Hr] 

This procedure configures a boot node in a cluster. It initializes 
the cluster authorization file, sets the volume label of SYS$SYSDEVICE 
to JOHNY.SYS, modifies SYS$SYSTEM:MODPARAMS.DAT, invokes AUTOGEN, 
and reboots the system with the new parameters. 

To ensure that you have the required privileges, invoke this 
procedure from the system manager’s account. 


WARNING - The cluster PASSWORD will not be echoed. 

Enter this cluster’s group number: 1011 
Enter this cluster’s password: 

Reenter the password for verification: 

Enter this node’s SCSSYSTEMID value: 2249 
Enter this node’s DECnet node name: JOHNY 
How many boot nodes will be in this cluster (1 or 2)? 1 

AUTOGEN computes the SYSGEN parameters for your configuration 
and then reboots the system with the new parameters. 

After the reboot, you many want to configure other nodes in 
your cluster. 


•/,SET-I-INTSET, login interactive limit=64, current interactive value = 0 
SYSTEM job terminated at 15-JUN-1987 09:30:33.21 


2.3 Securing the Cluster 

Because multiple clusters may coexist on a single Ethernet, mechanisms are 
provided to ensure the integrity of individual clusters and to prevent access 
to a cluster (accidental or deliberate) by an unauthorized node. 
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Cluster security mechanisms prevent problems that could otherwise occur 
under circumstances like the following: 

• When setting up a new cluster, the cluster manager specifies a group 
number identical to that of an existing cluster on the same Ethernet. 
(This condition is not as unlikely as it may at first appear, because cluster 
managers will probably not assign group numbers randomly.) However, 
provided each cluster's password is unique, the new cluster will form 
independently. 

• A satellite node user with access to a local system disk tries to join 
a cluster by executing a conversational SYSBOOT operation at the 
satellite's console. 

The following mechanisms are designed to help cluster managers perform 
security functions: 

• A cluster authorization file (SYS$COMMON: <SYSEXE> CLUSTER— 
AUTHORIZE.DAT), initialized during execution of BOOT— 
CONFIG.COM, and maintained with the Cluster—Authorize Utility 

• Control of conversational bootstrap operations on satellite nodes 
These mechanisms are discussed in Sections 2.3.1 and 2.3.2. 


2.3.1 Maintaining Cluster Security Data 

Security data is maintained in the cluster authorization file, 
SYS$COMMON: <SYSEXE> CLUSTER_AUTHORIZE.DAT, which contains 
the cluster group number and (in encrypted form) the cluster password. The 
file is accessible only to users with the SYSPRV privilege. 

Under normal conditions, you will not need to alter records in the 
CLUSTER_AUTHORIZE.DAT file interactively. However, if you suspect a 
security breach, for example, you may want to change the cluster password. 
In that case, you use the Cluster_Authorize Utility to make the change. 

Note that if your configuration has two system disks, each disk will have 
a copy of CLUSTER_AUTHORIZE.DAT. You must run the utility twice to 
update both copies (see Section 2.5.3). 

Caution 

If you change either the group number or password, you must 
reboot the entire cluster. 
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To invoke the Cluster_Authorize Utility, log in as system manager on the 
boot node and enter the following command: 

$ RUN SYS$SYSTEM:CLUSTER.AUTHORIZE 

When the utility responds with the CAF> prompt, you can enter any of the 
commands listed in Table 2-1. 


Table 2-1 

Summary of Cluster_Authorize Utility Commands 

Command 

Parameters/Qualifiers 

Function 

EXIT 

None 

Terminates the utility and returns control to DCL 
command level. 

HELP 

[command-name] 

[qualifier-name] 

Lists and explains utility commands and qualifiers. 

SET 


Updates a record in the cluster authorization 
file, SYSSCOMMON: <SYSEXE> CLUSTER— 
AUTHORIZE.DAT. (The SET command will create 
this file if it does not already exist.) Prompts for' 
cluster group number and password if they are not 
specified. If you press RETURN in response to a 
prompt, the current value will not be changed. 


/[NO]GROUP_NUMBER 

Group number must be in the range from 1 to 4095 
or 61440 to 65535. Specify /NOGROUP-NUMBER if 
the group number is not to be changed. 


/[NO]PASSWORD 

Password may be from 1 to 31 characters in length 
and may include alphanumeric characters, dollar 
signs, and underscores. Specify /NOPASSWORD if 
the current password is not to be changed. 

SHOW 

None 

Displays the cluster group number. 


Example 2-2 illustrates the use of the Cluster—Authorize Utility to change 
the cluster password on boot node JOHNY. 
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Example 2-2 Sample Interactive Cluster Authorize Session 


$ RUN SYS$SYSTEM:CLUSTER,AUTHORIZE 
CAF> SET/PASSWORD=’newpassword’ 

Enter cluster group number [1011] : IretI 
'/.CAF-I-GRPNOCHG, Group number not changed 
The cluster authorization file has been updated. 
The entire cluster should be rebooted. 

CAF> EXIT 
$ 


2.3.2 Controlling Conversational Bootstrap Operations 

When you add a satellite node to the cluster using SATELLITE— 
CONFIG.COM, the procedure asks whether you want to allow 
conversational bootstrap operations for the satellite (default is NO). If 
you press RETURN, SYSGEN parameter PE3 in the satellite's SYSGEN 
parameter file remains set to 0 to disable such operations. The parameter 
file, VAXVMSSYS.PAR, resides in the satellite's root directory on a boot 
node's system disk ('device': <SYSx.SYSEXE> ). You may later enable 
conversational bootstrap operations for a given satellite at any time by 
setting this parameter to 1. 

For example, to enable such operations for a satellite booted from root B on 
device JOHNY$DUAO, you would proceed as follows: 

1 Log in as system manager on the boot node. 

2 Invoke the System Generation Utility (SYSGEN) and enter the 
commands shown: 

$ RUN SYSSSYSTEM:SYSGEN 

SYSGEN> USE JOHNY$DUAO:<SYSB.SYSEXE>VAXVMSSYS.PAR 
SYSGEN> SET PE3 1 

SYSGEN> WRITE JOHNY$DUAO:<SYSB.SYSEXE>VAXVMSSYS.PAR 
SYSGEN> EXIT 

$ 
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2.4 Installing the DECnet-VAX Key, and Tailoring and Starting the Network 

After you have configured the boot node for cluster operation, you must 
install the DECnet-VAX key to activate full function DECnet-VAX capability 
on your VMS operating system. Before proceeding, note the following: 

• The cluster boot node requires a DECnet-VAX full function license. 

• Each satellite requires either a DECnet-VAX end node license or a 
DECnet-VAX full function license. 

To install the DECnet-VAX key on VAX boot nodes, follow instructions in 
the DECnet-VAX Key Installation Guide distributed with the DECnet-VAX 
media kit. For Micro VAX II or VAXstation II boot nodes, follow instructions 
in the DECnet-VAX media kit cover letter. 

When the key is installed, you perform the following operations to tailor the 
network for the cluster, and then you start the network. (For more detailed 
information on these operations, refer to the VAX/VMS Networking Manual.) 

• Configure the network on the cluster boot node, using the command 
procedure SYS$MANAGER:NETCONFIG.COM. 

• Enable service for the DECnet Ethernet adapter circuit that the boot node 
will use to service satellite nodes. When you execute NETCONFIG.COM 
in step 2, you will see a command that defines the circuit available on 
your system—for example, QNA-0 or UNA-O. Specify that circuit in 
step 3. 

• Define, in the boot node's executor database, a maximum address value 
that is large enough to accommodate future growth. 

• Optionally define an alias node identifier for the cluster. The cluster alias 
acts as a single node identifier that all participating cluster nodes can use 
to communicate with other nodes in the network. You establish an alias 
node identifier using NCP commands like those shown in step 3 for alias 
LAZRUS. (For more information on alias node identifiers, refer to the 
VAX/VMS Networking Manual.) Note that if you plan to define an alias 
node identifier, you must specify that the cluster boot node operate as 

a router node when you execute NETCONFIG.COM. Note further that 
you must later enable alias operations for satellite nodes, as described in 
Section 3.6. 

• Make remote node data available clusterwide. 

To perform these tailoring operations and start the network, proceed as 
follows: 

1 Log in as system manager on the boot node. 
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2 Execute the command procedure NETCONFIG.COM, entering 
information about your boot (executor) node when prompted, and 
responding YES when the procedure asks whether you want to configure 
the network ("want to go ahead and do it"). 

Caution 

When the procedure asks if you want the network started, be 
sure to answer NO, because you must first perform several 
additional tailoring operations. 

Example 2-3 shows typical responses for a cluster network configuration 
session using NETCONFIG.COM. 

Example 2-3 Sample Interactive Network Configuration Session 


$ 0NETCONFIG.COM 

DECnet-VAX network configuration procedure 

This procedure will help you define the parameters needed to get DECnet 
running on this machine. You will be shown the changes before they are 
executed, in case you want to perform them manually. 

What do you want your DECnet node name to be? [JOHNY]: |ret| 

What do you want your DECnet address to be? [2.201]: |retI 

Do you want to operate as a router? [NO (nonrouting)]: YES 

Do you want a default DECnet account? [YES]: |ret| 

Here are the commands necessary to set up your system. 


$ RUN SYS$SYSTEM:NCP 

DEFINE LINE QNA-0 STATE ON 
DEFINE CIRCUIT QNA-0 STATE ON COST 4 


Do you want to go ahead and do it? 


[YES] : | ret | 


(If the license is already installed) Do you want DECnet started? [YES] NO 
$ 
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3 Invoke the Network Control Program (NCP) Utility to enable circuit 
service, define a maximum address value for the boot node, and 
(optionally) define an alias node identifier for the cluster. For example: 

$ RUN SYS$SYSTEM:NCP 

NCP> DEFINE CIRCUIT QNA-0 SERVICE ENABLED 
NCP> DEFINE EXECUTOR MAXIMUM ADDRESS 1023 
NCP> DEFINE NODE 2.1 NAME LAZRUS 
NCP> DEFINE EXECUTOR ALIAS NODE LAZRUS 
NCP> EXIT 
$ 

The information you specify using these commands is entered in the 
boot node's DECnet-VAX permanent executor database and takes effect 
when you start the network. 

4 NETCONFIG.COM creates (in the boot node's 
SYS$SPECIFIC: <SYSEXE> directory) the file NETNODE— 
REMOTE.DAT, in which remote node data is maintained. To make 
this data available clusterwide, you must rename the file to the boot 
node's SYS$COMMON: <SYSEXE> directory: 

$ RENAME SYS$SPECIFIC:<SYSEXE>NETNODE_REMOTE.DAT - 
_$ SYS$COMMON:<SYSEXE>NETNODE_REMOTE.DAT 

Some sites with large networks maintain remote node data in a central 
database file. If this is the case at your site, and if you want to make 
the data available in your cluster, you can, after starting the network, 
copy remote node database entries from that central file. For example, 
if the file resides on node KATHY, you could enter the following NCP 
commands to copy entries from the permanent database on KATHY to 
the permanent database on your boot node, and then to update your 
volatile database: 

NCP> COPY KNOWN NODES FROM KATHY USING PERMANENT TO PERMANENT 
NCP> SET KNOWN NODES ALL 

Note that only node names and addresses are copied. See the VAX/VMS 
Networking Manual for more information on copying node databases. 

5 Start the network: 

$ SSTARTNET.COM 

6 To ensure that the network is started each time the system boots, 
add the following line to your site-specific startup command file 
(SYS$MANAGER:SYSTARTUP.COM): 

$ eSYS$MANAGER:STARTNET.COM 
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For more detailed information on DECnet-VAX configuration issues and 
procedures, refer to the VAX/VMS Networking Manual. 


2.5 Configuring an Extended Cluster 

Because a Local Area VAXcluster system disk supports a maximum of 13 
satellites, you must use a second system disk if your cluster is to include 
more than this number of satellites. Depending on your current configuration 
and available resources, you can configure an extended cluster in one of the 
following ways: 

• If your boot node is a VAX 8500 machine or larger, you can set up a 
second system disk on the machine, as described in Section 2.5.4. 

• If your boot node is a VAX machine smaller than a VAX 8500, or if it is a 
Micro VAX II or VAXstation II machine, you must configure a second boot 
node in the cluster and use that node's system disk as the second system 
disk. (See Sections 2.5.6 and 2.5.7.) 

CAUTION 

In a dual boot node configuration, the SYSGEN parameter 
QUORUM is always set to 2 on both boot nodes. Should one 
of these nodes fail, cluster operations will be suspended until 
the node rejoins the cluster. This condition is normal, and 
ensures the integrity of shared cluster resources. 

The next sections describe procedures that you can use to set up each of 
these configurations. 


2.5.1 Coordinating Cluster Common Files 

To prepare a common user environment for a Local Area VAXcluster 
configuration with two system disks, you must coordinate these system 
files: 

• SYSUAF.DAT 

• NETUAF.DAT 

• RIGHTSLIST.DAT 

• VMSMAIL.DAT 

• NETNODE_REMOTE.DAT 

• JBCSYSQUE.DAT 
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The method you use to coordinate the files will vary, depending on whether 
both system disks are to be configured on the same boot node, or whether 
there is to be one system disk on each of two boot nodes. 

If both system disks are to be configured on the same boot node, proceed as 
follows before adding the new disk. 

1 At the start of the file <V4COMMON.SYSMGR> SYSTARTUP.COM, 
include logical name definitions that point to the location of the 
cluster common files. For example, if the files are to be located on 
JOHNY$DUAO, you could define logical names like the following: 

$ DEFINE/SYSTEM/EXEC SYSUAF - 

JOHNY$DUAO: <V4C0MM0N. SYSEXE>SYSUAF. DAT 
$ DEFINE/SYSTEM/EXEC NETUAF - 

JOHNY$DUAO:CV4C0MM0N.SYSEXE>NETUAF.DAT 
$ DEFINE/SYSTEM/EXEC RIGHTSLIST - 

JOHNY$DUAO:<V4C0MM0N.SYSEXE>RIGHTSLIST.DAT 
$ DEFINE/SYSTEM/EXEC VMSMAIL - 

JOHNYSDUAO:<V4C0MM0N.SYSEXE>VMSMAIL.DAT 
$ DEFINE/SYSTEM/EXEC NETNODE.REMOTE - 

JOHNY$DUAO: <V4C0MM0N. SYSEXE> NETNODE.REMOTE. DAT 

These logical names must be defined before you add satellites. If you 
plan to add satellites before the next system reboot, you can define the 
names interactively. 

2 To ensure that both system disks are correctly mounted with each reboot, 
follow these steps: 

a. Copy the file SYS$EXAMPLES:CLU_MOUNT_DISK.COM to the 
directory <V4COMMON.SYSMGR> . 

b. In the file <V4COMMON.SYSMGR> SYSTARTUP.COM, 
immediately following the logical name definitions, include 
commands to mount the two system disks with appropriate volume 
labels. For example, if the system disks are JOHNY$DUAO and 
JOHNY$DUAl, you would include commands like these: 

$ QSYSSSYSDEVICE: <V4C0MM0N. SYSMGR>CLU_MOUNT_DISK. COM - 
JOHNYSDUAO: volume-label 

$ 0SYSSSYSDEVICE:<V4C0MM0N.SYSMGR>CLU_MOUNT_DISK.COM - 
JOHNYSDUAl: volume-label 

3 In the site-specific file used for queue setup, specify the location of the 
job controller queue file (JBCSYSQUE.DAT), using a command like the 
following: 

$ START/QUEUE/MANAGER JOHNYSDUAO: <V4C0MM0N. SYSEXE>JBCSYSQUE. DAT 
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If the second system disk is to be located on a second boot node, proceed as 
follows: 

1 After bringing up the second boot node, determine which node's system 
disk will contain the cluster common files. 

2 Repeat the steps listed above on both nodes. 


2.5.2 Starting the DECnet-VAX Network and MicroVMS Workstation 
Software in a Configuration with Two System Disks 

When a boot node in a Local Area VAXcluster configuration with two system 
disks is rebooted, logical names for cluster common files must be defined, 
and both system disks must be mounted (as described in Section 2.5.1), 
before either the DECnet-VAX network or MicroVMS Workstation Software 
is started. 

In the file <V4COMMON.SYSMGR> SYSTARTUP.COM, you must 
therefore include commands that define the logical names and mount the 
system disks before commands that start the DECnet-VAX network and 
workstation software. 

Caution 

During an initial installation of MicroVMS Workstation Software, 
the installation procedure inserts a command to start the software 
at the beginning of SYSTARTUP.COM . Thus, if you plan to install 
workstation software for the first time after setting up a Local 
Area VAXcluster configuration with two system disks, you must, 
after the workstation software installation completes, edit the file 
<V4COMMON.SYSMGR> SYSTARTUP.COM and move the 
workstation startup command to a position after the logical name 
definitions and mount commands described in Section 2.5.1. If 
your configuration has two boot nodes, you must edit the file on 
both boot nodes. 


2.5.3 Updating the Cluster Authorization File in a Configuration with Two 
System Disks 

A Local Area VAXcluster configuration with two system disks requires two 
copies of the the cluster authorization file, CLUSTER_AUTHORIZE.DAT— 
one for each system disk. If you want to alter either the cluster group 
number or password in such a configuration, you must run the Cluster— 
Authorize Utility twice to update both copies. 

If you have one system disk on each of two boot nodes, log in as system 
manager on each boot node in turn and run the utility as described in 
Section 2.3.1. 
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If both system disks are located on the same boot node, first log in as 
system manager on the boot node and run the utility to update CLUSTER— 
AUTHORIZE.DAT on the original system disk. Then log in as system 
manager on a satellite booted from the second system disk and run the 
utility again to update CLUSTER_AUTHORIZE.DAT on the second system 
disk. 


2.5.4 Setting Up a Second System Disk on a Cluster Boot Node 

To set up a second system disk on a cluster boot node, 1 proceed as 
follows, after you have coordinated cluster common files, as described in 
Section 2.5.1. 

1 Log in as system manager on the boot node, if you have not already 
done so. 

2 Place a blank disk in an appropriate drive and spin up the disk. 

3 Invoke the command procedure SYS$MANAGER:BOOT—CONFIG.COM 
and select the ADD function. The procedure will prompt you for the 
name of the new system disk. It will then back up the original system 
disk to the new one, delete from the new disk any duplicated system 
roots, and mount the disk clusterwide. Note that you will see VAX 
RMS error messages while the procedure deletes directory files. You can 
ignore these messages. 

Example 2-4 shows a typical interactive BOOT_CONFIG.COM ADD session 
on boot node JOHNY. 


1 Dual system disks are supported only on VAX 8500 or larger boot nodes. 
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Example 2-4 Sample Interactive BOOT_CONFIG.COM ADD Session 


$ 0BOOT_CONFIG.COM 

Boot Node Configuration Procedure 

This procedure can CONFIGURE a Local Area VAXcluster boot node 
or ADD another system disk. 

CONFIGURE a boot node or ADD another system disk [CONFIGURE]? ADD 

The ADD command creates another system disk by: 

o backing up the current system disk to the new system disk. 

o removing from the new system disk any system roots 
that are duplicated on the current system disk. 

WARNING - Do not proceed unless you have defined appropriate 
logical names for cluster common files in your 
site-specific startup procedures. See the documentation 
for instructions. 

Do you want to continue [NO]? YES 

What is the device name for the new system disk? DUA1: 

'/.DCL-I-ALLOC, _J0HNY$DUA1: allocated 

•/.MOUNT-1-MOUNTED, SCRATCH mounted on _J0HNY$DUA1: 

Backing up the current system disk to the new system disk... 


•/.MOUNT-1-MOUNTED, JOHNY.SYS mounted on _J0HNY$DUA1: 


Deleting all duplicated roots... 

Deleting directory tree SYSO... 

•/.DELETE-1-FILDEL, DUA1: <SYSO>DECNET. DIR; 1 deleted (2 blocks) 
•/.DELETE -1 - FILDEL, DUA1: <SYSO>SYSCBI. DIR; 1 deleted (2 blocks) 


System root SYSO deleted. 

Deleting directory tree SYS1... 

Example 2-4 Cont'd. on next page 
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Example 2-4 (Cont.) Sample Interactive BOOT_CONFIG.COM ADD Session 


‘/.DELETE-1-FILDEL, DUA1:<SYS1>DECNET.DIR; 1 deleted (2 blocks) 
•/.DELETE -1 - FILDEL, DUA1: <SYS1>SYSCBI. DIR; 1 deleted (2 blocks) 


System root SYS1 deleted. 


All the roots have been deleted. 

What is the unique label for the new system disk [J0HNY_SYS2]? I ret 1 
'/.MOUNT-1-MOUNTED, J0HNY.SYS2 mounted on _J0HNY$DUA1: 

The second system disk has been created. Satellites can now 
be added. 


2.5.5 Installing New Layered Products on a Boot Node with a Second System 
Disk 

Any layered products that were installed on your original system disk when 
you set up a second system disk will be accessible to satellite nodes that boot 
from the new system disk. 

You must, however, install on both system disks any new or updated layered 
products that you want to make available clusterwide. The quickest way to 
perform such installations is as follows: 

1 Log in as system manager on the boot node. 

2 Mount the layered product distribution medium in an appropriate drive 
and put in on line. 

3 Install the layered product following instructions in the installation 
document for the product. 

Use the GET (G) option of the VMSINSTAL.COM command procedure 
to place the product save sets in a disk directory. For example, if you 
are installing a product named CALENDAR from a VAX-11/785 console 
drive into the disk directory WORK: <NEWPRODUCTS> , you would 
first enter the following command: 

$ 0SYS$UPDATE:VMSINSTAL CALENDAR CSA1: OPTIONS G WORK:<NEWPRODUCTS> 
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To install the product from that directory, you would then enter this 
command: 

$ ®SYS$UPDATE:VMSINSTAL CALENDAR WORK:<NEWPRODUCTS> 

4 After the installation on the first system disk has completed, log in as 
system manager locally on a satellite node that is booted from the second 
system disk. 

5 Enter the same command that you used to install the product from the 
directory on the original system disk: 

$ QSYS$UPDATE:VMSINSTAL CALENDAR WORK:<NEWPRODUCTS> 

The layered product will be installed on the second system disk, and it will 
be accessible to satellite nodes that boot from that disk. 


2.5.6 Configuring a Second Boot Node in an Existing Cluster 

To configure a second boot node in an existing cluster, perform steps 1 

through 3 and 5 through 7 on that node; perform step 4 on the original boot 

node. 

1 Install the VMS operating system, as described in Section 2.1. 

2 Install the Local Area VAXcluster Software key as described in 
Section 2.2. 

3 Execute the command procedure SYS$MANAGER:BOOT_ 
CONFIG.COM, and select the CONFIGURE function. 

Caution 

When you execute this procedure, you must specify the same 
group number and password that you used for the original 
boot node. When the procedure asks how many boot nodes 
will be in the cluster, you must enter 2 to set the correct value 
(2) for the SYSGEN parameter QUORUM. 

4 Reexecute the procedure on the original boot node and specify 2 when 
the procedure asks how many boot nodes will be in the cluster. (Be sure 
not to change either the cluster group number or password.) 

5 Install the DECnet-VAX key, and tailor and start the network, as 
described in Section 2.4. 

6 Coordinate cluster common files, as described in Section 2.5.1. 

7 Install any layered products that must be available clusterwide. 
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2.5.7 Setting Up a New Cluster with Two Boot Nodes 

To set up a new cluster with two boot nodes, you must perform steps 1 
through 3 on both boot nodes, and then perform steps 4 through 6 on each 
in turn. Note that the first boot node will wait until quorum is reached (that 
is, until the second node comes up) before it continues booting and joins the 
cluster. 

1 Install the VMS operating system, as described in Section 2.1. 

2 Install the Local Area VAXcluster Software key, as described in 
Section 2.2. 

3 Execute the command procedure SYS$MANAGER:BOOT_CONFIG.COM 
and select the CONFIGURE function. 

Caution 

You must specify the same group number and password for 
both boot nodes. When the procedure asks how many boot 
nodes will be in the cluster, you must enter 2 to set the 
correct value (2) for the SYSGEN parameter QUORUM. 

4 Install the DECnet-VAX key and tailor and start the network, as 
described in Section 2.4. 

5 Coordinate cluster common files, as described in Section 2.5.1. 

6 Install any layered products that must be available clusterwide. Note 
that you must install any new or updated layered products on both boot 
nodes. 
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This chapter explains how to configure satellite nodes using the SATELLITE— 
CONFIG.COM command procedure in the boot node's SYS$MANAGER 
directory. That procedure, by prompting for certain information (listed in 
Table 3-2), allows you to configure satellites easily and reliably, without 
invoking VMS utilities directly. You use SATELLITE_CONFIG.COM to 
perform the following functions: 

• Add a satellite node to the cluster. 

• Remove a satellite node from the cluster. 

• Modify a Micro VAX II or VAXstation II satellite node's Ethernet hardware 
address in the boot node's network database. 

Table 3-1 describes the system and network management operations that 
these functions automate and shows the information for which each function 
prompts. 

Note that you can remove a satellite node or modify its Ethernet hardware 
address relatively quickly, working exclusively on the cluster boot node. But 
because the ADD function executes many system and network management 
operations, you should allow about twenty minutes to add a satellite. And 
you (or another responsible person) will be required to boot the satellite at 
its console terminal. 
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Table 3-1 Operations Automated by SATELLITE_CONFIG.COM 


Function Automated Operations 

ADD Establish a satellite node's root directory on a boot node's 

cluster common system disk. Directory name has the form 
'device': <SYSx> . Procedure prompts for device and root 
directory names , supplies valid defaults. 

Configure the network database to enable remote booting of the 
satellite. Procedure prompts for network information. 

Generate, in the directory 'device': <SYSx.SYSEXE> , 
system parameter files for the satellite (VAXVMSSYS.PAR, 
MODPARAMS.DAT); if local paging and swapping requested, 
generate SATELLITE_PAGE.COM. 

Generate an initial (temporary) startup procedure for the satellite. 
This procedure configures the network, runs AUTOGEN to set 
appropriate SYSGEN parameter values for the satellite, and reboots 
the satellite with normal startup procedures. 

Generate the satellite's page and swap files (PAGEFILE.SYS and 
SWAPFILE.SYS), either on a boot node's system disk or on the 
satellite's local disk. Procedure prompts for location and sizes of 
these files. 


REMOVE Delete the satellite's root directory and its contents from the 

boot node's system disk. Procedure prompts for device and root 
directory names. 

Configure the network database to disable remote booting of the 
satellite node. Procedure prompts for network information. 

MODIFY Modify MicroVAX II or VAXstation II satellite's Ethernet hardware 
address in a boot node's network database. Procedure prompts 
for DECnet node name and new Ethernet hardware address. 


The following sections explain how you prepare for and execute 
configuration functions using SATELLITE_CONFIG.COM. 
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3.1 Preparing to Execute SATELLITE_CONFIG.COM 

Before you execute the procedure, be sure to verify the following: 

• You are logged in to the system manager's account on the boot node 
with these process privileges: SYSPRV, OPER, CMKRNL, BYPASS, 
NETMBX. The privileges are required, because the procedure performs 
sensitive system operations. 

• The DECnet-VAX network is up and running, and service is enabled 
for the Ethernet adapter circuit that the boot node will use to connect to 
satellites. (See Section 2.4.) 

• You have at hand the satellite node data listed in Table 3-2. 

• If your configuration has two system disks, you have coordinated cluster 
common files, as described in Section 2.5.1. 

Sections 3.2, 3.3, and 3.4 provide examples of typical interactive 

configuration sessions. 

Caution 

You may not initiate concurrent SATELLITE_CONFIG.COM 
sessions. 


Table 3-2 Data Required by SATELLITE_CONFIG.COM 


Item 

Device name of cluster system 
disk on which satellite root 
directories will be created 

Satellite's root directory name on 
cluster system disk 


Satellite's DECnet node name 
Satellite's DECnet node address 


How To Specify Or Obtain 

Cluster manager specifies. Default is 
SYS$SYSDEVICE. 

Cluster manager specifies. Must be of the 
form SYSx, where x is a hexadecimal digit 
in the range 1 through 9 or A through D 
(for example, SYS1 or SYSA). Procedure 
supplies valid default. 

Network manager supplies. Name must 
begin with alpha character. 

Network manager supplies. 
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Table 3-2 (Cont.) Data Required by SATELLITE_CONFIG.COM 


Item 

How To Specify Or Obtain 

Satellite's Ethernet hardware 
address 

When Local Area VAXcluster software and 
DECnet-VAX network are running on boot 
node, follow these steps: 


1 For MicroVAX II and VAXstation II 
satellites, enter the following command 
at satellite's console-mode prompt: 


»> B/100 XQ 


For MicroVAX 2000 and VAXstation 2000 
satellites, enter the following commands at 
successive console-mode prompts: 1 


»> T 53 

2 ?»> 3 
»> B/100 ES 


2 Enter READ_ADDR at Bootfile: 
prompt. 

Location and sizes of satellite's 
page and swap files 

Cluster manager specifies. (If page and 
swap files are located on satellite's local 
disk, subsequent reboots of satellite will 
generate an error message. Message can 
be ignored.) 


1 1f the second prompt appears as 3 ?> > > , press RETURN. 


3.1.1 Setting Up Page and Swap Files 

When you add a satellite node to the cluster using SATELLITE _ 
CONFIG.COM, the procedure prompts for the sizes and location of the 
satellite's page and swap files. (The default sizes supplied by the procedure 
are mimimums.) Note that, depending on the configuration of your system 
disk and your network, you may realize a performance improvement by 
locating page and swap files on a satellite's local RD series disk, if such a 
disk is available. If you decide to use a local disk, you should specify a page 
file size of 20,000 blocks or more, and a swap file size of 12,000 blocks or 
more. 
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To set up page and swap files on a satellite's local disk, SATELLITE- 
CONFIG.COM creates (in the satellite's <SYSx.SYSEXE> directory on the 
boot node's system disk) the command procedure SATELLITE_PAGE.COM. 
This procedure executes when AUTOGEN reboots the satellite at the end of 
SATELLITE_CONFIG.COM, and it performs the following functions: 

• Mounts the satellite's local disk and sets its volume label to a name in 
the format 'node'_SCSSYSTEMID. 

• Installs the page and swap files on the local disk. 

To alter the volume label, follow these steps after the satellite has been 
added to the cluster: 

1 Enter a DCL command in the following format: 

$ SET VOLUME/LABEL=volume-label device-spec [:] 

Note that the SET VOLUME command requires write access (W) to the 
index file on the volume. If you are not the volume's owner, you must 
have either a system UIC or the SYSPRV privilege. 

2 Update SATELLITE_PAGE.COM to reflect the new label. 

To relocate the satellite's page and swap files—for example, from the 
satellite's local disk to the boot node's system disk, or the reverse—the 
easiest way is to remove the satellite from the cluster and then readd it, 
using SATELLITE_CONFIG.COM. 


3.1.2 Maintaining Network Configuration Data 

When you execute SATELLITE_CONFIG.COM for the first time, the 
procedure creates the file NETNODE_UPDATE.COM in the boot node's 
SYS$SPECIFIC: <SYSMGR> directory. This file, which is updated each 
time you add, remove, or modify satellite nodes, contains all essential 
network configuration data for the satellite. If an unexpected condition at 
your site should cause configuration data to be lost, you can use NETNODE— 
UPDATE.COM to restore it. You can also read the file when you need to 
obtain data about individual satellites. 

Example 3-1 shows the contents of the file after nodes LINDA and CHERYL 
have been added to the cluster. 
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Example 3—1 Sample NETNODE__UPDATE.COM File 


$ run sys$system:ncp 

define node LINDA address 2.55 

define node LINDA hardware address 08-00-2B-03-51-75 
define node LINDA load assist agent sys$share:niscs_laa.exe 
define node LINDA load assist parameter SYS$SYSDEVICE:<SYSA.> 
define node LINDA service circuit QNA-0 
define node CHERYL address 2.56 

define node CHERYL hardware address 08-00-2B-03-58-14 
define node CHERYL load assist agent sys$share:niscs_laa.exe 
define node CHERYL load assist parameter SYS$SYSDEVICE:<SYSB.> 
define node CHERYL service circuit QNA-0 


3.2 Adding a Satellite Node to the Cluster 

Adding a satellite node to the cluster is the only configuration function that 
you cannot perform entirely on the boot node, because the satellite must be 
booted locally. You will probably want to arrange for the satellite's intended 
user (or another responsible person) to stand by at the satellite's console 
terminal. Before proceeding, be sure you have all the information listed in 
Table 3-2. 

If your boot node has two system disks, be sure to specify the appropriate 
device when the procedure prompts for the device name of the satellite's 
system root. 

Note that because all nodes in a Local Area VAXcluster configuration 
must have the same DECnet area number, you must, when specifying 
the satellite's DECnet address, use the same area number that you used for 
the cluster boot node. 

While adding satellites, you may want to disable broadcast messages to 
your terminal. (The ADD function generates many such messages.) To 
disable the messages, you can enter the DCL command SET TERMINAL 
/NOBROADCAST. 

Example 3-2 illustrates the use of SATELLITE_CONFIG.COM to add 
satellite node LINDA to the cluster. 

Caution 

If for some reason either the boot node or the satellite should 
fail before the ADD function completes, you must, after normal 
conditions are restored, perform the REMOVE function to erase 
any invalid data, and then restart the ADD function. 
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Example 3-2 Sample Interactive SATELLITE_CONFIG.COM ADD Session 


$ 0SATELLITE_CONFIG.COM 

Satellite Configuration Procedure 

This procedure configures a satellite node in the cluster. 

It can ADD or REMOVE a satellite node, and it can MODIFY 
the network database. 

To ensure that you have the required privileges, invoke this 
procedure from the system manager’s account. 

If the local disk on the satellite node is to be INITIALIZED for 
paging and swapping, please be sure you are satisfied with the 
BACKUP of the local disk before proceeding. 

ADD, REMOVE or MODIFY a satellite node [ADD]? |ret| 

Verifying circuits in network database... 

What is the device name for the new system root [SYS$SYSDEVICE: ] ? [retI 

What is the name of the new system root [SYSA]? | ret I 

What is the DECnet node name of the satellite node? LINDA 

What is the DECnet node address of the satellite node? 2.55 

Allow conversational bootstraps on the satellite node [NO]? [ret] 

Creating directory tree SYSA... 

'/.CREATE -1 - CREATED, SYS$SYSDEVICE: <SYSA> created 
'/.CREATE-1-CREATED, SYS$SYSDEVICE:<SYSA.SYSEXE> created 
'/.CREATE-1-CREATED, SYS$SYSDEVICE:<SYSA.SYSLIB> created 
'/.SET-1-ENTERED, SYS$SYSDEVICE: <SYSO. XOOOOOO>SYSCOMMON.DIR; 1 entered as 
SYS$SYSDEVICE:<SYSA>SYSCOMMON.DIR; 

'/.CREATE-1-CREATED, SYS$SYSDEVICE: <SYSA. SYSTEST> created 
'/.CREATE-1-CREATED, SYS$SYSDEVICE: <SYSA. SYSMAINT> created 
'/.CREATE-1-CREATED, SYS$SYSDEVICE: <SYSA. SYSMGR> created 
'/.CREATE-1-CREATED, SYS$SYSDEVICE:<SYSA.SYSHLP> created 
'/.CREATE -1 - CREATED, SYS$SYSDEVICE: <SYSA. SYSHLP. EXAMPLES> created 
'/.CREATE-1-CREATED, SYS$SYSDEVICE: <SYSA. SYSUPD> created 
'/.CREATE-1-CREATED, SYS$SYSDEVICE: <SYSA. SYSMSG> created 
'/.CREATE-1-CREATED, SYS$SYSDEVICE: <SYSA. SYSERR> created 
'/.CREATE-1-CREATED, SYS$SYSDEVICE: <SYSA. SYSCBI> created 
System root SYSA created. 

What is the hardware address of the satellite node? 08-00-2B-03-51-75 
Updating network database... 

Size of pagefile for the new satellite [10000 blocks]? 20000 
Size of swap file for the new satellite [8000 blocks]? 12000 

May this procedure use a local disk on the satellite for paging and swapping? YES 
Creating temporary page file in order to boot LINDA for the first time... 

'/.SYSGEN-1-CREATED, SYS$SYSDEVICE: <SYSA. SYSEXE>PAGEFILE. SYS; 1 created 


Example 3—2 Cont'd. on next page 
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Example 3-2 (Cont.) Sample Interactive SATELLITE_CONFIG.COM ADD 

Session 


This procedure will now wait until the satellite node is a 
member of this cluster. 

Once the satellite node joins the cluster, this procedure 
will ask you which local disk it can use for paging and 
swapping. 

Please boot the satellite node now. 

Waiting for satellite node to boot... 

Waiting for satellite node to boot... 


(User enters boot command at satellite’s console-mode prompt (>») . 
For MicroVAX II and VAXstation II satellites, user enters B XQ. 

For MicroVAX 2000 and VAXstation 2000 satellites, user enters B ES.) 


The local disks 

on LINDA are: 






Device 

Device 

Error 

Volume 

Free 

Trans 

Mnt 

Name 

Status 

Count 

Label 

Blocks 

Count 

Cnt 

LINDA$DUAO: 

Online 

0 





LINDA$DUA1: 

Online 

0 






Which disk can be used for paging and swapping? LINDA$DUAO: 
May this procedure INITIALIZE LINDA$DUAO: [YES]? NO 
'/.MOUNT-I-MOUNTED, LINDA.2103 mounted on _LINDA$DUAO: 


PAGEFILE.SYS already exists on LINDA$DUAO: 

*************************************** 

Directory LINDASDUAO:[SYSO.SYSEXE] 

PAGEFILE.SYS;1 23000/23000 

Total of 1 file. 23000/23000 blocks. 

*************************************** 

What is the file specification for the page file on 
LINDA$DUAO: [ <SYSO.SYSEXE>PAGEFILE.SYS ]? [ret] 

•/.CREATE-1-EXISTS. LINDA$DUAO:<SYS0.SYSEXE> already exists 
This procedure will use the existing pagefile, 

LINDA$DUAO:<SYS0.SYSEXE>PAGEFILE.SYS;. 


Example 3-2 Cont'd. on next page 
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Example 3-2 (Cont.) Sample Interactive SATELLITE_CONFIG.COM ADD 

Session 


V.MOUNT-I-MOUNTED, LINDA.2103 mounted on _LINDA$DUAO: 


SWAPFILE.SYS already exists on LINDA$DUAO: 

*************************************** 

Directory LINDA$DUAO:[SYSO.SYSEXE] 

SWAPFILE.SYS;1 12000/12000 

Total of 1 file. 12000/12000 blocks. 

*************************************** 

What is the file specification for the swap file on 
LINDA$DUAO: [ <SYS0. SYSEXE>SWAPFILE. SYS ]? [ret] 

This procedure will use the existing swapfile, 
LINDA$DUAO:<SYS0.SYSEXE>SWAPFILE.SYS;. 

Waiting for AUTOGEN to reboot satellite... 

Waiting for AUTOGEN to reboot satellite... 


The satellite configuration procedure has successfully completed. 


3.3 Removing a Satellite Node from the Cluster 

The REMOVE function is a relatively quick operation that can be performed 
entirely on the boot node. Note, however, that you must shut down 
the satellite before removing it. If possible, use the command procedure 
SYS$SYSTEM:SHUTDOWN.COM to perform an orderly shutdown. 
Otherwise, press and release the satellite's HALT button. 

If your boot node has two system disks, be sure to specify the appropriate 
device when the procedure prompts for the device name of the satellite's 
system root. 

Example 3-3 illustrates the use of SATELLITE__CONFIG.COM to remove 
satellite node LINDA from the cluster. 

Note 

Because the REMOVE function deletes the satellited entire 
root directory tree, it generates VAX RMS error messages while 
deleting directory files. You can ignore these messages. 
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Example 3-3 Sample Interactive SATELLITE_CONFIG.COM REMOVE Session 


$ QSATELLITE_CONFIG.COM 

Satellite Configuration Procedure 

This procedure configures a satellite node in the cluster. 

It can ADD or REMOVE a satellite node, and it can MODIFY 
the network database. 

To ensure that you have the required privileges, invoke this 
procedure from the system manager’s account. 

If the local disk on the satellite node is to be INITIALIZED for 
paging and swapping, please be sure you are satisfied with the 
BACKUP of the local disk before proceeding. 

ADD, REMOVE or MODIFY a satellite node [ADD]? REMOVE 

The REMOVE command disables a satellite node by: 

o deleting its root directory tree. 

o removing its remote booting information 
from the network database. 


What is the device name for the system root [SYS$SYSDEVICE:]? I ret I 
What is the name of the system root? SYSA 
What is the DECnet node name of the satellite node? LINDA 
Verifying network database... 

Deleting directory tree SYSA... 

'/.DELETE-1-FILDEL, SYS$SYSDEVICE: <SYSA>SYSCBI .DIR; 1 deleted (1 block) 
'/.DELETE-1-FILDEL, SYS$SYSDEVICE: <SYSA>SYSERR.DIR; 1 deleted (1 block) 
'/.DELETE-W-FILNOTDEL, error deleting SYS$SYSDEVICE: <SYSA>SYSEXE. DIR; 1 
-RMS-E-MKD, ACP could not mark file for deletion 
-SYSTEM-F-DIRNOTEMPTY, directory file is not empty 

'/.DELETE-W-FILNOTDEL, error deleting SYS$SYSDEVICE:<SYSA>SYSHLP.DIR; 1 
-RMS-E-MKD, ACP could not mark file for deletion 
-SYSTEM-F-DIRNOTEMPTY, directory file is not empty 
'/.DELETE-1-FILDEL, SYS$SYSDEVICE: <SYSA>SYSLIB . DIR; 1 deleted (1 block) 
'/.DELETE -1 - FILDEL, SYS$SYSDEVICE: <SYSA>SYSMAINT. DIR; 1 deleted (1 block) 
'/.DELETE-W-FILNOTDEL, error deleting SYS$SYSDEVICE:<SYSA>SYSMGR.DIR; 1 
-RMS-E-MKD, ACP could not mark file for deletion 

-SY STEM-F-DIRNOTEMPTY, directory file is not empty _ 

Example 3-3 Cont'd. on next page 
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Example 3-3 (Cont.) Sample Interactive SATELLITE_CONFIG.COM REMOVE 

Session 

•/.DELETE-I-FILDEL, SYSSSYSDEVICE:<SYSA>SYSMSG.DIR;1 deleted (1 block) 

'/.DELETE-I-FILDEL, SYS$SYSDEVICE:<SYSA>SYSTEST.DIR; 1 deleted (1 block) 
’/.DELETE-I-FILDEL, SYS$SYSDEVICE:<SYSA>SYSUPD.DIR; 1 deleted (1 block) 

'/.DELETE-I-FILDEL, SYS$SYSDEVICE:<SYSA.SYSEXE>MODPARAMS.DAT; 1 deleted (1 block) 
‘/.DELETE-I-FILDEL, SYSSSYSDEVICE:<SYSA.SYSEXE>PAGEFILE.SYS;1 deleted (4608 blocks) 
’/.DELETE-I-FILDEL, SYS$SYSDEVICE:<SYSA.SYSEXE>STARTUP 1.COM; 1 deleted (5 blocks) 
‘/.DELETE-I-FILDEL, SYSSSYSDEVICE: <SYSA.SYSEXE>VAXVMSSYS.PAR;2 deleted (15 blocks) 
•/.DELETE-I-FILDEL, SYSSSYSDEVICE:<SYSA.SYSEXE>VAXVMSSYS.PAR; 1 deleted (15 blocks) 
•/.DELETE-I-FILDEL, SYSSSYSDEVICE:<SYSA.SYSEXE>VMSPARAMS.DAT; 1 deleted (36 blocks) 
’/.DELETE-I-FILDEL, SYSSSYSDEVICE:<SYSA.SYSHLP>EXAMPLES.DIR; 1 deleted (1 block) 
‘/.DELETE-I-FILDEL, SYSSSYSDEVICE;<SYSA.SYSMGR>VMSIMAGES.DAT; 1 deleted (6 blocks) 
'/.DELETE-I-TOTAL, 15 files deleted (4694 blocks) 

’/.DELETE-I-FILDEL, SYSSSYSDEVICE:<SYSA>SYSEXE.DIR; 1 deleted (1 block) 

•/.DELETE-I-FILDEL, SYSSSYSDEVICE:<SYSA>SYSHLP.DIR; 1 deleted (1 block) 

•/.DELETE-I-FILDEL, SYSSSYSDEVICE:<SYSA>SYSMGR.DIR; 1 deleted (1 block) 

•/.DELETE-I-TOTAL, 3 files deleted (3 blocks) 

•/.DELETE-I-FILDEL, SYSSSYSDEVICE:<000,000>SYSA.DIR; 1 deleted (1 block) 

System root SYSA deleted. 

Updating network database... 

The satellite configuration procedure has successfully completed. 


3.4 Modifying a MicroVAX II or VAXstation II Satellite Node's Ethernet 
Hardware Address 

You perform the MODIFY function when you want to specify a new Ethernet 
hardware address for a MicroVAX II or VAXstation II satellite, should its 
Ethernet device need replacement. 

Example 3-4 illustrates the use of SATELLITE_CONFIG.COM to specify a 
new hardware address for satellite node LINDA. 
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Example 3-4 Sample Interactive SATELLITE_CONFIG.COM MODIFY Session 


$ 0SATELLITE_CONFIG.COM 

Satellite Configuration Procedure 

This procedure configures a satellite node in the cluster. 

It can ADD or REMOVE a satellite node, and it can MODIFY 
the network database. 

To ensure that you have the required privileges, invoke this 
procedure from the system manager’s account. 

If the local disk on the satellite node is to be INITIALIZED for 
paging and swapping, please be sure you are satisfied with the 
BACKUP of the local disk before proceeding. 

ADD, REMOVE or MODIFY a satellite node [ADD]? MODIFY 

What is the DECnet node name of the satellite node? LINDA 

What is the new hardware address [08-00-2B-03-51-75]? 08-00-3B-05-37-78 

Updating network database... 

The satellite configuration procedure has successfully completed. 


3.5 Controlling Clusterwide Broadcast Messages 

When a satellite node joins the cluster, broadcasts for all message classes 
are initially enabled for the satellite by default. Satellite node users can 
disable such broadcasts selectively by including a form of the DCL command 
SET BROADCAST in their LOGIN.COM files. For example, the following 
command would disable OPCOM and SHUTDOWN messages: 

$ SET BROADCAST 3 (NOOPCOM, NOSHUTDOWN) 

Note that broadcasts to the operator console terminal (OPAO:) on 
workstation nodes are disabled by default and should remain disabled 
at all times. Users who want to receive broadcast messages can create a 
terminal window, and then enter the DCL command REPLY/ENABLE. 

(This command requires OPER privilege.) For more detailed information 
on workstation operations, refer to the documentation supplied with the 
workstation software. 

In large clusters, state transitions (nodes joining or leaving the cluster) will 
generate many multiline OPCOM messages on the boot node's console 
device. Cluster managers can abbreviate such messages by including the 
DCL command REPLY/DISABLE=CLUSTER in the appropriate site-specific 
startup command file, or by entering the command interactively from the 
system manager's account on the boot node. 
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3.6 Enabling Cluster Alias Operations 

If you have defined an alias node identifier for your cluster as described in 
Section 2.4, you can enable alias operations for satellites after the satellites 
have joined the cluster. To enable such operations (that is, to allow a satellite 
to accept incoming connect requests directed toward the cluster alias node 
identifier), follow these steps: 

1 Log in on the satellite node locally as system manager. 

2 Invoke the Network Control Program (NCP) Utility and enter these 
commands: 

NCP> SET EXECUTOR STATE OFF 

NCP> DEFINE EXECUTOR ALIAS INCOMING ENABLED 

NCP> EXIT 

$ 

3 Start the network on the satellite node: 

$ 0SYSSMANAGER:STARTNET.COM 


3.7 Setting Up MSCP-Served Local Disks 

To conserve nonpaged pool, the MSCP Server is not loaded on satellite 
nodes, and their local disks are not served to the cluster. (On the boot node, 
the MSCP Server is always loaded.) If you want to serve a satellite's local 
disks (for example, if the disks contain data that must be available to other 
cluster nodes), proceed as follows: 

1 Log in on the satellite node locally as system manager. 

2 Edit the file SYS$SYSTEM:MODPARAMS.DAT and add the following 

MSCP.LOAD = 1 

A value of 1 for the AUTOGEN symbol MSCP_LOAD specifies that 
the MSCP Server is to be loaded and local disks served when the node 
reboots. 

3 Verify that the volume label of each local disk is unique in the cluster. 

If it is not, you can use the DCL command SET VOLUME/LABEL to 
specify a new label. For example: 

$ SET VOLUME/LABEL=volume-label device-spec [:] 
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4 Invoke the AUTOGEN.COM command procedure with the GETDATA, 
REBOOT, and INITIAL parameters: 

$ aSYS$UPDATE:AUTOGEN GETDATA REBOOT INITIAL 

Note that when the system reboots, the MSCP Server will be loaded with a 
set of default values that is adequate for most situations. (For information on 
these values, and for instructions on modifying them, see Section C.9.) 

If you wish to disable service for local disks, you must set the value of the 
AUTOGEN symbol MSCP-LOAD to 0 and then invoke AUTOGEN to reboot 
the satellite. 


Caution 

Do not attempt to serve disks by loading the MSCP Server with 
the System Generation Utility (SYSGEN) and then using DCL 
SET DEVICE/SERVED commands. This procedure could disrupt 
normal cluster operations. 
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4 


Guidelines for Satellite Node Users 


This chapter explains procedures that users of satellite nodes may follow to 

• Join and leave the cluster. 

• Perform operations that affect other users. 

• Identify and report problems. 

These procedures are discussed in the next sections. 


4.1 Joining and Leaving the Cluster 

To include a satellite node in the cluster, the cluster manager (or 
another responsible individual) executes a command procedure 
(SYS$MANAGER:SATELLITE_CONFIG.COM) that requires the satellite 
node to be booted at its console terminal. Depending on site policy, this 
individual may contact the satellite node s intended user to arrange a 
mutually convenient time for the boot operation. 

Occasionally, it may be necessary to remove one or more satellite nodes 
from the cluster, usually to perform various update, maintenance, or 
trouble-shooting operations. At these times, the cluster manager (or 
another responsible individual) may contact satellite node users to make 
arrangements. 


4.2 Performing Operations that Affect Other Users 

Satellite node users have access to clusterwide resources for file sharing, 
data storage, and batch processing. In addition, they can use the satellite's 
processor to perform editing, program development, and other interactive 
tasks locally. 

These users should be aware, however, that they can, by performing certain 
operations, affect other cluster members and the normal functioning of 
the entire cluster. They must, therefore, consult the cluster manager (or 
another responsible individual) before they perform either of the following 
operations: 

• Halt, power down, or reboot a satellite node. Note that under normal 
conditions, a satellite node should be active (powered up) at all times. 
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• Modify any files in the SYS$COMMON directory (if the user is 
privileged). 

By showing consideration for other users, individuals who share cluster 
resources can help ensure the continuing trouble-free operation of the entire 
cluster. 


4.3 Identifying and Reporting Problems 

Occasionally, users may notice a brief slowdown of interactive response time. 
This condition may occur when a satellite node joins or leaves the cluster. 
Users should be aware that the condition is usually temporary. 

If, however, a user's node fails to respond to command input for protracted 
periods (longer than a few minutes), or if a user repeatedly obtains 
unexpected results from operations that worked in the past, that user should 
proceed as follows: 

• Report to the cluster manager (or another responsible individual) 
immediately any protracted interruption of interactive response. 

• For instances of unexpected system responses, try to reproduce such 
responses several times. If the problem persists, make a record of the 
following items: 

— The operation being attempted when the problem occurred 
— User input and the system's response 
— The conditions under which the problem occurred 

• Provide the cluster manager (or another responsible individual) with a 
detailed problem report, including, if possible, an example of both user 
input and the system's response. 

For effective problem analysis, timely notification and accurate information 
are crucial. 
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Installing the Operating System on MicroVAX II or 
VAXstation II Boot Nodes 


This appendix describes the procedure for installing the VMS operating 
system on MicroVAX II or VAXstation II boot nodes. 

WARNING 

The software installation procedure overwrites the entire contents 
of the system disk. If your system disk contains files that you 
want to save, be sure to back up the disk before proceeding. 

Before you install the system software, your hardware must be installed and 
checked for proper operation. 

Obtain the DECnet area number and node number for your processor from 
either your network or cluster manager before starting the installation. You 
will need this information to complete the installation procedure. 

Here are definitions for some terms that may not be familiar to you. 

Table A—1 Installation Procedure Terms 


Term Definition 


load-device 


system-device 


console-mode 
device name 

VMS device name 

spin up/spin 
down 

boot 


The drive that holds the distribution medium during the 

installation. You must specify the physical device name 
when you are prompted for the load-device. 

The drive that holds the system disk you are building. 

You must specify the physical device name when you are 
prompted for the system-device. 

The name of the load-device or system-device you specify 
for commands entered at the console-mode prompt 
(>>>)• 

The name of the load-device or system-device you specify 
for commands entered at the DCL prompt ($). 

To spin up means to bring a disk drive up to operating 
speed; to spin down means to bring it to a gradual stop. 

Literally "bootstrap load"; the process of software loading 
itself into a computer. 
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Be sure you have all the items listed on the distribution kit bill of materials. 
If your kit is incomplete, notify the DIGITAL Software Distribution Center 
and request priority shipment of any missing components. 

This procedure assumes that the system is powered up when you start the 
installation. 

1 Decide which drive will hold the distribution medium and which drive 
will hold the system disk. 

2 Turn on the console terminal, if you have not already done so. 

3 Place the distribution medium in the load-device, write protect it, and 
put it on line. 

4 If you are building a removable system disk, place a blank disk in the 
system-device. 

5 Spin up the system disk but do not write protect it. 

6 When the console-mode prompt (> > > ) appears, boot standalone 
BACKUP from the distribution medium on the load-device, using a 
command in the following format. See the second column in Table A-2 
to determine the console-mode name for your load-device. 

>» B load-device 


Table A—2 Determining Names for Load-Device and System-Device 


Device Type 

Console-Mode 
Device Name 1 

VMS Device Name 1 

RA60 

DUcu 

DJcu 

RA80, RA81, RD54 

DUcu 

DUcu 

TK50, TU81 

MUcu 

MUcu 

’Variable c designates the device controller, and variable u is the device unit 
number. 


7 When the standalone system finishes booting, it announces itself and 
asks for the date and time: 

VAX/VMS Version ’version-number’ DD-MMM-YYYY HH:MM 

PLEASE ENTER DATE AND TIME (DD-MMM-YYYY HH:MM) 
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8 Enter the date in day-month-year format, and the time in hours and 
minutes, using the 24-hour clock format. For example, if the time is 3:58 
P.M. and the date is June 17, 1987, type 

PLEASE ENTER DATE AND TIME (DD-MMM-YYYY HH:MM) 17-JUN-1987 15:58 

9 When standalone BACKUP finishes booting, it identifies itself and 
displays the dollar sign ($) prompt: 

•/.BACKUP-1-IDENT, stand-alone BACKUP . . . 

$ 

10 Enter a command in the following format to restore the required save set. 
See the third column in Table A-2 to determine the VMS names of the 
load-device and system-device. 

$ BACKUP/VERIFY load-device:REQUIRED/SAVE system-device: 

This BACKUP command builds a system disk that includes a DIGITAL- 
provided set of volume parameters, including a cluster factor (disk access 
scheme) of 1. Most volume parameters can be changed later with the 
SET VOLUME command. However, to change the cluster factor you 
must back up the system to a volume that has been previously initialized 
to the desired cluster factor. To save the volume's initial parameter 
values, use the /NOINITIALIZE qualifier when you back up the system. 

11 Depending on the distribution medium, it takes between 10 and 30 
minutes to restore the required files. The following message indicates the 
start of the verification pass: 

•/.BACKUP-1-STARTVERIFY, starting verification pass 

When the required files are restored, standalone BACKUP identifies itself 
and displays the dollar sign prompt ($), indicating that the verification 
pass is finished. 

12 Press and release the HALT button to put the system in console mode. 

13 Boot the system disk, using a command in the following format. See the 
second column in Table A-2 to determine the console-mode device name 
for the system-device. 

>>> B system-device 

14 When the boot is complete, the system displays a message like the 
following: 

VAX/VMS Version ’version-number* DD-MMM-YYYY HH:MM 
Please enter the date and time (DD-MMM-YYYY HH:MM): 
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15 Enter the date in day-month-year format, and the time in hours and 
minutes, using the 24-hour clock format. For example, if the time is 4:30 
P.M. and the date is June 17, 1987, type 

Please enter the date and time (DD-MMM-YYYY HH:MM): 17-JUN-1987 16:30 

16 The procedure asks you which drive holds the distribution medium. 
Enter the device name for the load-device. See the third column in 
Table A-2 to determine the VMS name of the load-device. 

Enter drive holding distribution kit (DDCU): load-device: 

17 The procedure next gives you the opportunity to build a cluster common 
system disk and asks if you want to know more about such disks. 

18 When the procedure asks if you want a cluster common system disk, 
enter Y (or YES): 

Do you want to generate a cluster common system disk [N]? YES 

19 The next message prompts you for the first of two SYSGEN parameters: 

In order to successfully boot the system, you must provide a nonzero 
value for the SYSGEN parameter SCSSYSTEMID and a nonblank value for 
the SYSGEN parameter SCSNODE. See the Guide to VAXclusters for information 
on setting up other SYSGEN parameters after the system is installed. 

Enter this node’s SCSSYSTEMID value: 

Enter a value equal to your system's DECnet-VAX node number in 
decimal plus 1024 times the DECnet-VAX area number. 

For example, if your DECnet-VAX node number is 201 and your 
DECnet-VAX area number is 2, the value for SCSSYSTEMID is 
calculated as follows: 

201 + (2 * 1024) = 2249 

20 The procedure prompts you for the second parameter: 

Enter this node’s SCSNODE name: 

Enter your system's DECnet-VAX node name. 

21 The procedure restores the rest of the operating system and displays 
appropriate messages: 

Restoring library save set. 

*/,BACKUP-1-STARTVERIFY, starting verification pass 
Restoring optional save set. 

'/.BACKUP-1-STARTVERIFY, starting verification pass 

22 At this point, the procedure creates a V4COMMON directory tree. 
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23 The procedure prompts you for new passwords for the SYSTEM, 

SYSTEST, and FIELD accounts. Passwords must be at least six characters 
in length. 

24 When you change the passwords, the procedure creates your RIGHTS 
database and displays a message indicating that AUTOGEN will compute 
SYSGEN parameters for your configuration and reboot the system with 
those parameters. The procedure also lists tasks that you may want to 
perform after the upgrade completes. 

25 The procedure then indicates the start of AUTOGEN with this message: 
Running AUTOGEN - Please wait. 

When AUTOGEN finishes, the system displays a sequence of messages 
that begins like this: 

The system is shutting down to allow the VAX/VMS system to boot 
with the generated site-specific parameters and installed images. 

26 The system reboots automatically. When the following message appears, 
the reboot is complete, and the operating system is running. 

/iSET I-INTSET, login interactive limit=64, current interactive value = 0 
SYSTEM job terminated at DD-MMM-YYYY HH:MM:SS.CC 
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Upgrading the Operating System on MicroVAX II 
or VAXstation 11 Boot Nodes 


This appendix explains how to perform the following operations: 

• Upgrade the VMS operating system to VMS Version 4.6 on existing 
MicroVAX II and VAXstation II boot nodes. 

• Upgrade the MicroVMS operating system to VMS Version 4.6 on 
MicroVAX II and VAXstation II systems that will become boot nodes 
in a new Local Area VAXcluster configuration. 

Note that the preparatory steps described in Section B.2 vary, depending on 
whether you are upgrading a VMS or a MicroVMS system. Once you have 
performed these steps, the upgrade procedure is the same for both VMS and 
MicroVMS systems. 


B.1 System Upgrade Contingencies 

Before you attempt to upgrade your system, you should be aware of the 

following contingencies: 

• If you have changed the names of system directories in your current 
operating system or if you have deleted system hies from them, the 
upgrade procedure may not work correctly. You must restore your 
operating system to a standard system before you can begin the upgrade. 

• The upgrade procedure does NOT work across the network. 

• Neither the system disk nor the distribution medium can be moved from 
one device to another during the upgrade procedure. 

• The page, swap, dump, and authorization files are purged to one version 
each as part of the upgrade procedure. 

• All files in the [SYSERR] directory are deleted. 

• All operator and accounting logs are deleted. To save these files, move 
them to a user directory before starting the upgrade. 

To complete the upgrade procedure, you need the VMS Version 4.6 

distribution medium. 
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B.2 Preparing to Upgrade the Operating System 

To ensure that the upgrade completes successfully, DIGITAL recommends 
that you back up the system disk. This operation accomplishes the following: 

• Preserves the original system disk. 

• Improves disk performance by making free space on the new system disk 
contiguous. 

The following conditions must also be met: 

• The system disk must contain a minimum of 27,000 free blocks. To 
confirm the free-block count of the system disk, enter the following DCL 
command: 

$ SHOW DEVICES SYS$SYSDEVICE 

• The system page file must contain at least 4604 blocks. 

To confirm the number of blocks in the system page file, enter the 
following DCL command: 

$ 0SYS$UPDATE:SWAPFILES 

The SWAPFILES.COM command procedure displays the current sizes of 
the page, swap, and dump files and prompts you to enter new values. 
Press RETURN to retain the current values. If the page file contains 
fewer than 4604 blocks, enter the value 4604 when the procedure 
displays this prompt: 

Enter new size for paging file: 

The procedure then displays the following prompt: 

Enter new size for system dump file: 

Enter new size for swapping file: 

Press RETURN in response to both prompts. 

• SYSGEN parameters must be set to the following values for VMS and 
MicroVMS systems, respectively, and the system must be rebooted. 
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Parameter 

Value for VMS 

Value for MicroVMS 

ALLOCLASS 

0 

not applicable 

SCSNODE 

blank (" ") 

blank (" ") 

SCSSYSTEMID 

unused value 

not applicable 

STARTUP_P1 

"MIN" 

not applicable 

VAXCLUSTER 

0 

not applicable 


You can check and reset the values of these parameters, as shown for 
SCSNODE in the following example. 


$ RUN SYS$SYSTEM:SYSGEN 
SYSGEN> USE CURRENT 
SYSGEN> SHOW SCSNODE 


Parameter Name 

Current 

Default 

Minimum 

Maximum 

Unit 

Dynamic 

SCSNODE 

"JOHNY " 

ii it 

ii it 

"ZZZZ" 

Ascii 


SYSGEN> SET SCSNODE "" 
SYSGEN> WRITE CURRENT 
SYSGEN> SHOW SCSNODE 







Parameter Name 

Current 

Default 

Minimum 

Maximum Unit 

Dynamic 

SCSNODE 

n ii 

ii n 

ii ii 

"ZZZZ" 

Ascii 



SYSGEN> EXIT 


After you have reset the SYSGEN parameters for your system, invoke 
the command procedure SYS$SYSTEM:SHUTDOWN.COM to shut down 
and reboot the system. When the procedure asks if you want the system 
to be rebooted automatically, answer Y (or YES). Note that to enable the 
upgrade to continue automatically, you must set the restart switch on 
the processor contol panel to automatic restart. (Refer to the hardware 
documentation for your processor.) 

• When the system comes up, enter the following command to prevent 
users from logging in to the system during the upgrade: 

$ SET LOGINS/INTERACTIVE=0 

Suggestion 

Consider having a second terminal logged in for doing 
support tasks during the upgrade. 
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• If you are upgrading an existing VMS system to Version 4.6, you must 
reconfigure all available devices. Follow these steps: 

1 Invoke SYSGEN and enter the commands shown: 

$ RUN SYSSSYSTEM:SYSGEN 
SYSGEN> AUTOCONFIGURE ALL 
SYSGEN> EXIT 

2 Execute STARTUP CONFIGURE: 

$ OSYSSSYSTEM: STARTUP CONFIGURE 

• If you are upgrading a MicroVMS system to VMS Version 4.6, you must 
shut down the DECnet-VAX network and stop any active queues. 
Follow these steps: 

1 Remain logged in under the system manager's account, SYSTEM. 

2 Invoke the NCP Utility and enter the commands shown to shut 
down the network: 

$ RUN SYSSSYSTEM:NCP 
NCP> SET EXECUTOR STATE OFF 
NCP> EXIT 

3 Enter the following command at the DCL command prompt ($) to 
stop active queues: 

$ STOP/QUEUE/MANAGER 


B.3 Performing the Upgrade 

To perform the upgrade, follow these steps: 

1 Insert the distribution medium in an appropriate drive, write protect it, 
and put it on line. 

2 Invoke the VMSINSTAL command procedure by entering the following 
command: 

$ 0SYSSUPDATE:VMSINSTAL 

When VMSINSTAL displays the following prompt, press RETURN: 

Are you satisfied with the backup of your system disk [YES]? 

3 VMSINSTAL then displays the following prompt: 

* Where will the distribution volumes be mounted: 


B—4 













Upgrading the Operating System on MicroVAX II or VAXstation II Boot Nodes 


Enter the physical device name of the drive holding the distribution 
medium, using the format ddcu —DJcu for RA60; MUcu for TK50. 

4 When VMSINSTAL displays the * Products: prompt, enter VMS046. 

5 VMSINSTAL then displays the following message and prompt: 

Please mount the first volume of the set on ’ddcu’: 

Are you ready? 

If you have not already done so, place the distribution medium in an 
appropriate drive, write protect it, and put it on line. Type Y and press 
RETURN. 

6 VMSINSTAL displays the following messages: 

‘/.MOUNT-1-MOUNTED, SYSTEM mounted on _ddcu: 

The following products will be processed: 

VMS V4.6 

Beginning installation of VMS V4.6 at 14:27 
'/,VMSINSTAL-I-RESTORE, Restoring product save set A. . . 

Depending on the distribution medium, this step takes between 5 and 10 
minutes. 

7 VMSINSTAL displays a series of messages that describe cautions and 
requirements related to completing the upgrade. After the messages are 
displayed, the following prompt appears: 

Do you want to continue? (Y/N): 

• To interrupt the upgrade to comply with any of the conditions listed, 
type N and press RETURN. The procedure displays the following 
prompt: 

Enter the products to be processed from the next distribution volume set. 

* Products: 

• To terminate the procedure and return to the DCL prompt ($), 
press CTRL/Z. If you terminate the upgrade at this point, you must 
reinvoke VMSINSTAL when you are ready to resume the upgrade. 

• To proceed with Phase 1 of the upgrade, type Y and press RETURN. 
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B.3.1 Upgrade Phase 1 

The remainder of the upgrade consists of five phases. This section describes 

the first phase. 

1 The procedure gives you the opportunity to build a cluster common 
system disk and asks if you want to know more about such disks. When 
the procedure asks if you want a cluster common system disk , you must enter 
Y (or YES): 

Do you want to generate a cluster common system disk [N]? YES 

2 The procedure prompts you for new passwords for the SYSTEM, 
SYSTEST, and FIELD accounts. 

3 The procedure turns off disk quotas on the system disk. Ignore any error 
messages about disk quotas being disabled. 

4 The procedure stops OPCOM and the error formatter (ERRFMT). 

5 The procedure purges directories and removes installed images. 

6 The procedure purges all accounting data files, operator logs, and the 
directory [SYSERR]; ignore any error messages about files not being 
purged. 

7 The procedure deletes all JNL files in the root directory and in all of its 
subdirectories. Ignore any "file not found" error messages. 

8 The procedure builds the directory tree [SYSF] and deletes all the old 
operating system files that will not be needed if the system needs to be 
rebooted during Phase 1 of the upgrade. This step takes approximately 
20 minutes. 

9 The upgrade procedure restores the Version 4.6 required save set. 

10 The procedure purges the page, swap, dump, and authorization files and 
puts the most current versions in the new directory tree. 

11 The procedure uses AUTOGEN to save your old SYSGEN parameters 
and sets up the system to continue with Phase 2. 

12 The procedure displays messages stating that it is shutting down the 
system, that the system disk and distribution medium must not be 
moved during the upgrade, and that SYSGEN parameters must not be 
changed while the system reboots. 

When the system shutdown has completed, halt the system by pressing 
the halt button on the processor control panel. Then, reboot the system 
by entering the following command at the console-mode prompt 
(> > > ), where ddcu is the name of the system disk: 
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»> B/F0000000 ddcu 

13 The system prompts you to enter the date and time, and continues 
automatically with Phase 2. 


Note 

Should the system fail to reboot in Phases 2 through 4, halt the 
system and enter the following command at the console-mode 
prompt: 

»> B/F0000000 ddcu 


B.3.2 Upgrade Phase 2 

This section describes the second phase of the upgrade procedure. 

1 The system displays the following messages: 

VMS Version 4.6 25-JUN-1987 15:26 

Continuing with VAX/VMS V4.6 Upgrade Procedure. 

Upgrade Phase 2 25-JUN-1987 15:28 

2 The upgrade procedure removes the remaining files from the old version 
of the operating system. (This step takes approximately 20 minutes.) 

3 The procedure then restores to the system disk the library and optional 
save sets. 


B.3.3 Upgrade Phase 3 

This section describes the third phase of the upgrade procedure. 

1 The following system message is displayed on your console device: 
Continuing with VAX/VMS V4.6 Upgrade Procedure. 

Upgrade Phase 3 25-JUN-1987 15:48 

2 The upgrade procedure merges new versions of the VMS system files (for 
example, DCLTABLES, HELP, and LIBRARY FILES) with existing files. 
This step takes approximately 10 to 15 minutes. 

3 The procedure removes the directory entries for page, swap, dump, and 
authorization files from the old directory tree. 

4 The procedure deletes all the remaining accounting data files, operator 
logs, and all files in the [SYSERR] directory. 
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5 The upgrade procedure merges all the miscellaneous user files that exist 
in the old system directories into the new set of system directories, 
temporarily called [SYSF.SYS*]. The amount of time this takes depends 
on the number of user files. Ignore any "file not found" error messages. 

6 The procedure deletes the system directory tree containing the old 
version of the system files. 


B.3.4 Upgrade Phase 4 

This section describes the fourth phase of the upgrade procedure. 

1 The following system message is displayed on your console device: 
Continuing with VAX/VMS V4.6 Upgrade Procedure. 

Upgrade Phase 4 25-JUN-1987 16:00 

2 The upgrade procedure corrects the back links for the system directories. 
This step requires only a few seconds, and the procedure displays a 
message when it has completed. 

3 The procedure gives you instructions on how to reboot the system and 
then shuts down the system. 

When the shutdown has completed, halt the system by pressing the 
halt button on the processor control panel. Then, reboot the system by 
entering the following command at the console-mode prompt (> > > ), 
where ddcu is the name of the system disk: 

>>> B ddcu 


B.3.5 Upgrade Phase 5 

This section describes the fifth phase of the upgrade procedure. 

1 The system displays the following messages: 

VMS Version 4.6 25-JUN-1987 16:30 

Continuing with VAX/VMS V4.6 Upgrade Procedure. 

Upgrade Phase 5 25-JUN-1987 16:32 

2 The upgrade procedure deletes the temporary [SYSF] directory tree. 

3 The procedure purges files that were used only during the upgrade 
procedure. 

4 The procedure displays messages listing tasks that you may want to 
perform after the upgrade completes. 
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5 The procedure autoconfigures all devices on the system. 

6 The procedure runs AUTOGEN to determine the new SYSGEN 
parameters. (This step takes approximately 5 to 10 minutes.) 

7 The system reboots automatically after AUTOGEN has finished running. 

8 You may be prompted to enter the date and time. When a message like 
the following apprears, the reboot is complete, and the operating system 
is running. 

/.SET-I-INTSET, login interactive limit=64, current interactive value = 0 
SYSTEM job terminated at DD-MMM-YYYY HH:MM:SS.CC 

Note 

If you are upgrading from VMS Version 4.5A or 4.5C, you will 
see informational and warning messages like the following 
when AUTOGEN begins to reboot the system. Once you 
have installed the Local Area VAXcluster Software key, the 
messages will not reappear at subsequent reboots. 

VAX/VMS Version ’version-number’ DD-MMM-YYYY HH:MM 

waiting to form or join VAXcluster 

7.STAC0NFIG-I-L0ADSECDB, loading the Local Area VAXcluster security database 

SYSGEN'/,W-N0MSG, Message number 00000910 

PEDRIVER.EXE 

'/.STACONFIG-W-WARNING, unable to locate PEDRIVER, STS = 00000908 


If you are upgrading a Micro VMS system to VMS Version 4.6, 
you will see the Micro VMS banner when the system reboots 
at the end of the upgrade. At subsequent reboots, however, 
the system will display the VMS banner. 

9 Install the mandatory update. The mandatory update is found on a 
separate distribution medium. To install the mandatory update, refer to 
the discussion of post-upgrade procedures in the VMS Version 4.6 Release 
Notes. 

10 Install the Local Area VAXcluster Software key. 

11 Install the DECnet-VAX key. 

12 Install any other optional software products listed in the Layered 
Products Caution section of the VMS Version 4.6 Release Notes. 
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Caution 

Always back up the system disk after applying new system 
software with any software application procedure. It is essential 
to have a current backup copy of the system disk. 
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The following release notes apply for Version 1.2 of Local Area VAXcluster 
Software running on the VMS Version 4.6 operating system. 


C.1 Updating SYS$SYSTEM:MODPARAMS.DAT Files When Upgrading an 
Existing Local Area VAXcluster Configuration to Version 4.6 

Before starting the upgrade procedure in Local Area VAXcluster 
configurations running VMS Version 4.5A or 4.5C, you must perform the 
following operations: 

1 Edit the file SYS$SYSTEM:MODPARAMS.DAT on the boot node 
and remove entries that specify values for the following SYSGEN 
parameters: 

• LOCKDIRWT 

• MVTIMEOUT 

• PASTDGBUF 

• RECNXINTERVAL 1 

• SPTREQ 

In Version 4.6, AUTOGEN sets appropriate new values for the 
parameters. 

2 Edit the file [SYSx.SYSEXE]:MODPARAMS.DAT in the root directories 
for each satellite node and remove entries that specify values for any of 
these parameters. 

After you have upgraded to Version 4.6 on the boot node, reboot each 
satellite with AUTOGEN, specifying the parameters GETDATA, REBOOT, 
INITIAL. 


If you have set the value for RECNXINTERVAL to 40 seconds because you want to boot GPX systems from 
an asynchronous terminal (VT100 or VT200 series), do not remove the entry for this parameter. For more 
information on this condition, refer to Section C.7. 


C-1 














Release Notes 


C.2 Maintaining MODPARAMS.DAT Files 

Each time you execute either BOOT_CONFIG.COM or SATELLITE— 
CONFIG.COM, AUTOGEN appends entries for several SYSGEN parameters 
to the file SYS$SYSTEM:MODPARAMS.DAT on the boot and satellite nodes, 
respectively. The appended entries override any earlier entries for those 
parameters in the files. While the appended entries do not affect normal 
system operations, you may want to remove the earlier entries to make the 
files more readable. 


C.3 Observing Ethernet Configuration Restrictions 

You must observe the following restrictions when configuring your Ethernet 
for a Local Area VAXcluster environment. Note that the term station 
designates both processors and terminal servers such as DECserver. 

For detailed information on Ethernet device characteristics, refer to the 
appropriate hardware manuals. 

• No more than 1023 stations may be connected to a single Ethernet. 

• No more than one Local Network Interconnect (DELNI) device may 
share a common Ethernet transceiver connection. For example, two 
DELNIs wired in series may not be connected to an Ethernet transceiver. 

• No bridge that provides less than full 10-megabit Ethernet throughput 
may be connected between stations. 

• No bridge (such as a satellite link) that introduces propagation delays 
may be used between stations. 


C.4 Rebooting a Satellite Node with an Operating System on a Local Disk 

In some circumstances, cluster software reboots satellite nodes automatically. 
Before booting a satellite node, the boot procedures check for the presence 
of an operating system on the node's local disk. If an operating system (for 
example, a MicroVMS system) is found, that system —not the Local Area 
VAXcluster operating system —will be booted. 

If an operating system is installed on a satellite's local disk, one 
of the following measures should be taken before performing any 
operation that causes an automatic reboot—for example, executing 
SYS$SYSTEM:SHUTDOWN.COM with the REBOOT option, or using 
SATELLITE_CONFIG.COM to add that node to the cluster: 

• Rename the directory file ddcu: <000000> SYSO.DIR on the local disk 
to ddcu: <000000> SYSx.DIR (where SYSx is a root other than SYSO, 
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SYSE, or SYSF). Then enter the DCL command SET FILE/REMOVE to 
remove the old directory entry for the boot image SYSBOOT.EXE: 

$ RENAME DUAO:<000000>SYS0.DIR DUAO:<000000>SYS1.DIR 
$ SET FILE/REMOVE DUAO:<SYSEXE>SYSB00T.EXE 

For subsequent reboots of the system from the local disk, enter a 
command in the format B/xOOOOOOO at the console-mode prompt 
(>>>). For example: 

»> B/1000000 

• Disable the local disk. To disable the local disk on MicroVAX II or 
VAXstation II machines, press the READY button so that the light is off. 
(This option is not available if the satellite's local disk is being used for 
paging and swapping.) 


C.5 Defining the Logical Name MOM$LOAD as a Search List after Installation 

of DECserver Terminal Server Software 

The systemwide executive-mode logical name MOM$LOAD is defined during 
installation of the Local Area VAXcluster Software kit. If you have defined 
this name on your system, be aware that your definition will be superseded. 

However, because software for DECserver terminal servers also uses 
this logical name, you must redefine the name as a search list if 
you install DECserver software. After installing DECserver software, 
edit the appropriate site-specific startup file in the boot node's 
SYS$COMMON: <SYSMGR> directory and alter as follows the command 
that defines the MOM$LOAD logical name: 

$ DEFINE/SYSTEM/EXECUTIVE.MODE M0M$L0AD - 

SYSSSYSR00T:<DECSERVER>,SYS$C0MM0N:<M0M$SYSTEM> 


C.6 Respecifying Cluster Group Numbers 

Local Area VAXcluster group numbers must be within the range from 1 
to 4095 or 61440 to 65535. If, during a previous Local Area VAXcluster 
installation, you have specified a group number outside the legal range, you 
must run the Cluster—Authorize Utility to specify a new group number and 
then reboot the entire cluster. (See Section 2.3.1.) 
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C.7 Adjusting RECNXINTERVAL Parameter to Boot VAXstation ll/GPX 
Systems from Console Terminal Port 

If you want to boot a VAXstation II/GPX system from a standard 
asynchronous terminal (VT100, VT200 series) connected to the machine's 
console terminal port, you must first increase the value of the SYSGEN 
parameter RECNXINTERVAL to 40 seconds on each node in the cluster. 


C.8 Loading the Mass Storage Control Protocol (MSCP) Server on Satellite 
Nodes 

On satellite nodes, the MSCP Server is not loaded by default. For 
instructions on loading the server, refer to Section 3.7. 


C.9 Using AUTOGEN to Modify Mass Storage Control Protocol (MSCP) Server 
Values 

In Local Area VAXcluster configurations, the MSCP Server is always loaded 
with the following set of default qualifier values: 


MSCP 

Qualifier 

Units 

Boot Node 

Default Values 

Satellite Node 

Default Values 

BUFFER 

bytes 

32768 (64 pages) 

8192 

MAXIMUM 

bytes 

8192 (16 pages) 

8192 

MINIMUM 

bytes 

4096 (8 pages) 

4096 

PACKETS 

number per host 

4 

4 

HOSTS 

number 

15 

15 

TIMEOUT 

seconds 

100 

100 

PRIORITY 

number 

4 

4 


Performance testing has shown that these values are adequate for most 
situations. If for some reason you find it necessary to alter the default 
values, use the following AUTOGEN symbols to specify new values in the 
file SYS$SYSTEM:MODPARAMS.DAT on the boot or satellite node. Then 
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invoke AUTOGEN with the GETDATA, REBOOT, and INITIAL parameters 
to reboot the node with the new values. 


AUTOGEN Symbol 

Units 

MSCP_BUFFER 

bytes 

MSCP_MAXIMUM 

bytes 

MSCPJVIINIMUM 

bytes 

MSCP_PACKETS 

number per host 

MSCP—HOSTS 

number 

MSCP_TIMEOUT 

seconds 

MSCP—PRIORITY 

number 


For example, if you add the line MSCP_BUFFER=65536 to the file 
SYS$SYSTEM:MODPARAMS.DAT on node CHERYL, 128 pages of 
nonpaged pool will be allocated for the MSCP buffer area when CHERYL 
reboots. 

For more information on SYSGEN MSCP qualifier values, refer to the 
VAX/VMS System Generation Utility Reference Manual. 


C.10 Error and Warning Messages To Be Ignored 

In the Local Area VAXcluster environment, it is normal for certain routine 
operations to generate error or warning messages. These operations and 
associated messages are discussed in the following sections. Unless otherwise 
noted, you can ignore the messages. 


C.10.1 Upgrading the Operating System on Existing Boot Nodes Running VMS 
Version 4.5A or 4.5C 

When upgrading an existing Local Area VAXcluster boot node running VMS 
Version 4.5A or 4.5C, you will see informational and warning messages like 
the following when AUTOGEN begins to reboot the system. You can ignore 
the messages. 
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VAX/VMS Version ’version-number’ DD-MMM-YYYY HH:MM 
waiting to form or join VAXcluster 

•/.STACONFIG-I-LOADSECDB, loading the Local Area VAXcluster security database 

SYSGENV.W-NOMSG. Message number 00000910 

PEDRIVER.EXE 

'/.STACONFIG-W-WARNING, unable to locate PEDRIVER, STS = 00000908 


When the upgrade is complete, you must reinstall the Local Area VAXcluster 
key, as described in Section 2.2. Once the key is installed, the messages will 
not reappear at subsequent reboots. 


C.10.2 Booting a Satellite Node During SATELLITE_CONFIG.COM ADD Phase 

When a satellite node boots during the procedure's ADD phase, another 
command procedure, SYS$MANAGER:NETCONFIG.COM, executes. 
NETCONFIG.COM invokes the Authorize Utility, which, at that point, 
will generate the following error and informational messages: 

'/,UAF-E-UAEERR , invalid username, username already exists 
'/,UAF-I-N0M0DS , no modifications made to system authorization file 
y.UAF-I-RDNOMODS, no modifications made to rights database 


C.10.3 Shutting Down a Satellite Node During SATELLITE_CONFIG.COM 
ADD Phase 

During its ADD phase, SATELLITE_CONFIG.COM invokes the 
AUTOGEN.COM command procedure with the parameters GETDATA 
REBOOT INITIAL. AUTOGEN then performs an orderly shutdown on the 
satellite node. During this initial shutdown procedure, you will see the 
following error message: 

•/.SYSTEM-F-DEVOFFLINE, device is not in configuration or not available 
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C.10.4 Booting a Workstation Node before MicroVMS Workstation Software Is 
Installed 

If you boot a workstation node before workstation software is installed, you 
will see SYSGEN warning and error messages like the following: 

•/.SYSGEN-W-OPENIN, error opening SYS$C0MM0N: <SYSEXE>VCDRIVER. EXE; as input 
•/.SYSGEN-E-FNF, file not found. 

After you install workstation software, the messages will not reappear at 
subsequent reboots. 


C.10.5 Starting the DECnet-VAX Network on MicroVAX II Or VAXstation II 
Boot Nodes before Adding Satellites 

After starting the network on a MicroVAX II or VAXstation II boot node, 
messages reporting various DECnet-VAX events (4.7, 4.10, 4.15, 0.7) will 
be displayed until you have added the first satellite. These messages are 
normal. 


C.10.6 Breaking Port-To-Port Virtual Circuit Connections 

Port-to-port virtual circuit connections, required for cluster internode 
communication, are maintained by the port emulator driver 
(PEDRIVER.EXE). When connections are broken, the driver displays one 
or more messages in the following format: 

’/.PEAO, Software is Closing Virtual Circuit - REMOTE NODE ’nodename’ 

The 'nodename' will be that of the satellite node. (Note that the 
corresponding error log entry for the device PEAO: in the file 
SYS$ERRRORLOG:ERRLOG.SYS is "PACKET SIZE VIOLATION".) 

The %PEA0 message will be displayed at the boot node's console device 
under the following circumstances, and with the frequency indicated: 

• Whenever a satellite node boots (two to four times). 

• Whenever a satellite node shuts down or crashes (one to three times). 

• Whenever a cable or Ethernet adapter fails (at least once). In this case, 
you must make arrangements to have the cable or adapter repaired or 
replaced. 


The message may also be displayed once at the satellite node's console 
terminal when the node boots. In that case, the 'nodename' will be that of 
the boot node. 
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C.10.7 Running the User Environment Test Package (UETP) Ethernet Test 

The UETP Ethernet test (UETUNASOO) produces error messages like the 
following when run in the Local Area VAXcluster environment: 

*********************** UETINIT01 ** Error count = 1 ***************** 

-UETP-E-TEXT, Error running UETUNASOO.EXE for controller XQA - final status was: 
-SYSTEM-F-BADPARAM, bad parameter value 
•/,UETP-S-C0PY_L0G, Copy of log from testing XQA follows: 

•/.UETP-S-BEGIN, UETUNASOO beginning at 15-JUN-1987 10:17:16.08 
*********************** UNAS_XQA ** Error count = 1 ***************** 

-UETP-E-ABORT, UNAS.XQA aborted at 15-JUN-1987 10:17:16.89 
-SYSTEM-F-BADPARAM, bad parameter value 
'/.UETP-F-ENDED, UETUNASOO ended at 15-JUN-1987 10:17:16.91 

The error messages occur because the Ethernet device has been allocated to 
the cluster itself. 
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coordinating for two system disks®2-11 
Cluster group number®2-2 

respecifying within legal range ®C-3 
Cluster password®2-2 
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Computer Interconnect (Cl) device* 1-4, 
2-2 

Conversational bootstrap 
See Security functions 


D 


DECnet-VAX network 

alias node identifier, defining for cluster* 
2-8 

alias operations, enabling for satellite 
nodes*3-13 

area number and node name 

obtaining prior to installation of VMS 
operating system* A-1 
area number and node number 
using to calculate value of 

SCSSYSTEMID parameter* A-4 
circuit service, enabling for cluster boot 
node*2-8 

configuring on boot node using 
NETCONFIG.COM command 
procedure* 2-8 

Ethernet hardware address, modifying for 
satellite node* 3-11 
expected messages when running on 
MicroVAX II or VAXstation II boot 
node before adding satellites *C-7 
installing key • 2-8 
license requirements*2-8 
maximum address value, defining for 
cluster boot node* 2-8 
NETCONFIG.COM command procedure, 
sample interactive session* 2-9 
NETNODE_REMOTE.DAT file, renaming 
to SYS$C0MM0N directory* 2-10 
NETNODE_UPDATE.COM command 
procedure, using to restore satellite 
configuration data *3-5 
Network Control Program (NCP)*2-10 
remote node data, making available 
clusterwide* 2-8 

remote node database entries, copying* 
2-10 


DECnet-VAX network (cont'd.) 

restoring satellite network configuration 
data *3-5 

same area number required for all nodes* 
3-6 

starting the network *2-10 

in dual system disk configuration* 
2-13 
tailoring *2-8 

DECserver terminal server software 

redefining M0M$L0AD logical name after 
installing in cluster* C-3 

DELNI 

See Local Network Interconnect 

DEQNA 

See QBUS Network Adapter 


E 


Ethernet 

configuration restrictions *C-2 
Ethernet hardware address 
See Satellite node 


G 

Group number 

See Cluster group number 

~ 


Halting a satellite node 
user action *4-1 

Hierarchical Storage Controller (HSC) device* 
1-4, 2-2 


I 


Installation 

configuring a second boot node in the 
cluster* 2-17 

configuring boot node for cluster 
operation • 2-2 
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Installation (cont'd.) 

installing new layered products on a boot 
node with two system disks *2-16 
of DECnet-VAX key *2-8 
of Local Area VAXcluster Software key* 
2-2 

of VMS operating system *2-1, A-1 
setting up a new cluster with two boot 
nodes*2-18 

setting up a second system disk on a 
cluster boot node* 2-14 
setting up cluster security database *2-2 
tailoring DECnet-VAX network *2-8 
upgrading VMS operating system *2-1 


J 


Joining the cluster 
user action *4-1 


L 


Layered product 

installing on a boot node with two system 
disks*2-16 

installing on second boot node *2-17 
when to install* 1-3 
Leaving the cluster 
user action *4-1 

Local Network Interconnect (DELNI) 
restriction for use*C-2 


M 


Mass Storage Control Protocol (MSCP) 
Server 

See MSCP Server 
MicroVAX II processor 

installing VMS operating system when 
used as cluster boot node* A-1 
minimum DEQNA revision level 
requirement* 1-2 

minimum memory requirement* 1-2 
restrictions for use as boot node* 1-1 


Modifying a satellite node's Ethernet 
hardware address* 3-11 
MODPARAMS.DAT file 

created during SATELLITE_CONFIG.COM 
ADD phase *3-2 

maintaining in Version 4.6 Local Area 
VAXcluster configuration* C-2 
updating when upgrading a Local Area 
VAXcluster configuration to Version 
4.6 • C-1 

using AUTOGEN symbols to modify MSCP 
Server values* C-5 
M0M$L0AD logical name 

defining as search list after installation of 
DECserver terminal server software* 
C-3 

MSCP Server 

default values for boot and satellite nodes 
• C-4 

serving local disks on satellite nodes* 
3-13 

using AUTOGEN to load on satellite 
nodes*C-4 

using AUTOGEN to modify values*C-4 


N 


NETCONFIG.COM command procedure 
See DECnet-VAX network 
NETNODE_UPDATE.COM command 
procedure 

See DECnet-VAX network 
Network 

See DECnet-VAX network 
Network Control Program (NCP) 

See DECnet-VAX network 


o 


OPAO: workstation operator console 
terminal 

See Workstation node 
OPCOM messages 

See Broadcast messages 
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Optional software product 
See Layered product 

p~ 


Page file (PAGEFILE.SYS) 

created for satellite node during 
SATELLITE_CONFIG.COM ADD 
phase *3-2, 3-4 
Password 

See Cluster password 


Q 


QBUS Network Adapter (DEQNA) 

minimum revision level requirement • 1-2 


R 


RA series disk 

used as system disk for MicroVAX II boot 
node*1-1 
RD54 disk 

used as system disk for MicroVAX II or 
VAXstation II boot node* 1-1 
RD series disk 

See Satellite node 
Rebooting a satellite node 
user action *4-1 

if an operating system is installed on 
local disk* C-2 
RECNXINTERVAL parameter 

adjusting to boot VAXstation ll/GPX 
systems from console terminal port* 
C-4 

Removing a satellite node *3-9 
Reporting problems 
user action *4-2 


s 


SATELLITE_CONFIG.COM command 
procedure 
functions *3-1 


SATELLITE_CONFIG.COM command 
procedure (cont'd.) 
preparing to execute *3-3 
required information *3-3 
system files created during ADD phase for 
satellite node* 3-2 
using to add satellite nodes *3-6 
using to modify satellite Ethernet hardware 
address* 3-11 

using to remove satellite nodes *3-9 
SATELLITE_PAGE.COM command 
procedure 

created during SATELLITE_CONFIG.COM 
ADD phase *3-2 

used to set up page and swap files for 
satellite nodes* 3-4 
Satellite node 
adding *3-6 

booting, user action *3-6 
breaking port-to-port virtual circuit 
connections* C-7 
disabling conversational bootstrap 
operations* 2-7 

Ethernet hardware address, modifying* 
3-11 

expected device error message when 
adding to cluster* C-6 
functions* 1-1 
legal systems* 1-2 

maintaining network configuration data* 
3-5 

modifying files in SYS$COMMON 
directory 
user action *4-1 

obtaining Ethernet hardware address *3-3 
RD series disk used for local paging and 
swapping* 1-1 

rebooting if an operating system is 
installed on local disk* C-2 
removing *3-9 

restoring network configuration data *3-5 
restricted operations *4-1 
setting up page and swap files *3-4 
shutting down before removing from 
cluster *3-9 
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Satellite node (cont'd.) 

system files created during SATELLITE— 
CONFIG.COM ADD phase* 3-2 
SCSNODE parameter 

specifying during installation of VMS 
operating system* A-4 
SCSSYSTEMID parameter 

calculating value from DECnet-VAX area 
number and node number* A-4 
specifying during installation of VMS 
operating system* A-4 
Security functions 

BOOT_CONFIG.COM command procedure, 
using to set up cluster security 
database *2-2 

Cluster_Authorize Utility (CLUSTER- 
AUTHORIZE) 

sample interactive session *2-5 
using to alter cluster security data* 
2-5 

cluster authorization file (CLUSTER- 
AUTHORIZE.DAT)* 2-5 
updating in dual system disk 
configuration *2-13 
controlling conversational bootstrap 
operations on satellite nodes *2-7 
overview* 2-4 
Setup procedure 

adding a second system disk on a cluster 
boot node (VAX 8500 or larger)* 
2-14 

configuring an extended cluster *2-11 
configuring a second boot node in the 
cluster *2-1 7 

coordinating cluster common files for two 
boot nodes* 2-11 

coordinating cluster common files for two 
system disks* 2-11 

installing new layered products on a boot 
node with two system disks *2-16 
normal sequence* 1-2 
overview* 1-2 

setting up a new cluster with two boot 
nodes*2-18 


Shutdown messages 

See Broadcast messages 
Shutting down a satellite node 
user action *4-1 
Swap file (SWAPFILE.SYS) 

created for satellite node during 
SATELLITE_CONFIG.COM ADD 
phase *3-2, 3-4 

SWAPFILES.COM command procedure • B-2 
SYSB00T.EXE image 

renaming before rebooting satellite if 
an operating system is installed on 
satellite's local disk*C-3 
System directory 
naming *B-1 

System Generation Utility (SYSGEN) 
SCSNODE parameter*B-2 
System page file*B-2 


u 


Upgrade procedure • 2-1 , B-1 

caution for performing on existing Local 
Area VAXcluster configuration* 2-1 
contingencies* B-1 
continuing *B-5 
free block requirement • B-2 
interrupting *B-5 
messages to be ignored *C-5 
network restriction • B-1 
null SCSNODE requirement • B-2 
performing • B-4 
Phase 1 • B-6 
Phase 2 • B-7 
Phase 3 • B-7 
Phase 4* B-8 
Phase 5* B-8 
preliminaries* B-1 
preparing to perform • B-2 
system page file size requirement*B-2 
terminating *B-5 

updating SYS$SYSTEM:MODPARAMS.DAT 
files in existing Local Area VAXcluster 
configuration *C-1 
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User Environment Test Package (UETP) 

expected error messages when running 
Ethernet test* C-8 


v 


VAXstation II processor 

minimum DEQNA revision level 
requirement* 1-2 

minimum memory requirement* 1-2 
restrictions for use as boot node* 1-1 
VAXVMSSYS.PAR file 

created during SATELLITE_CONFIG.COM 
ADD phase *3-2 

VMSINSTAL.COM command procedure 
installing Local Area VAXcluster Software 
key *2-2 


installing new layered products on a boot 
node with two sytstem disks *2-16 
VMSINSTAL command procedure*B-4 
Volume label 

modifying for satellite's local disk *3-4 


w 


Workstation node 

controlling broadcasts to operator console 
terminal (OPAO:)* 3-12 
expected warning and error messages if 
booted before workstation software 
installed *C-7 
Workstation software 

starting in dual system disk configuration* 
2-13 

when to install • 1-3 
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